Philip Lowman wrote:
I've never read that shared libraries are faster than static executables. One would think that, if anything, all of the hoops the OS has to run through to map all of the symbols would cause applications that use shared libraries to be slower to startup then statically built executables.
The mapping happens pretty much automatically as it is usually done by an indirect table. This indirect table does add some overhead to runtime execution, but with current machines this is negligible.
Loading all the code for a library can take some time (some seconds or minutes), even with today's machines.
If the same shared library is used by multiple programs, loading the code in memory needs to happen only once. With static libraries, you always have to load the code regardless and as you say, you keep several copies of the same or similar code in memory.
Most modern OSes also support the concept of delay loaded dsos. That is, shared dso files which are loaded only when a function to them is referenced, not just at startup of the executable. This allows an executable to be linked to a shared library but not have to load it unless the user actually uses a function belonging to the dso. There's no way to do that with static linking.
Good OSes like linux will also often cache the access to shared libraries, making reopening the same .so several times almost immediate. Static executables are hardly ever cached.
If you are also loading a library already used by your window manager (usually some KDE or Gnome library on linux these days, but also some other common libs like libz, libpng, etc), the shared library will probably not even need to be loaded at all, as the window manager already did it for you. Again, with static linking you loose that.
All those benefits can lead a program using shared libraries to start up faster than if it had been linked statically. Of course, this does not mean it will indeed do so, just that it may.
-- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
