To view parent comment, click here.
To read all comments associated with this story, please click here.
Vanders,
"That's not how shared libraries work. There is no more code required (at run time) to call a function in a shared library than there is in calling a function within the executable."
You're kind of missing my point, though. I know that shared library functions are mapped into the same address space as static functions, and can be called the same way. But the fact that a function belongs to a shared library implies that it must abide by a well defined calling convention, and subsequently translate it's internal variables to and from this interface. There are optimizations that can take place in a static binary that cannot take place with a shared library.
For example, we obviously cannot do inter-procedural analysis and optimization against a shared library function (since the shared library function is undefined at compile time). Theoretically, using static binaries, an optimizing compiler could analyze the call paths and eliminate all the glue code. Trivial functions could be inlined. Calling conventions could be ignored since there is no need to remain compatible with external dependencies.
In the ideal world, object files would be an intermediate representation like java class files, or .net assemblies. Not only would the run time compilation optimize for the current platform, but it could also perform inter-procedural optimization that might eliminate all costs currently associated with glue code.
I can't help but feel that the time and effort needed to do that well would be significant, yet only save a tiny fraction of the load and link time for a binary that uses classic shared libraries.





Member since:
2005-07-06
That's not how shared libraries work. There is no more code required (at run time) to call a function in a shared library than there is in calling a function within the executable.