Shared libraries

[David F. Carlson]

In article <323 at mtndew.UUCP>, friedl at mtndew.UUCP (Steve Friedl) writes:
> Ruud Harmsen writes:
> > Is it [shared libraries] any slower or faster than the normal way?
> 
> Conor P. Cahill writes:
> > Slower link and program initialization, but from then on execution time
> > should be the same.
> 
> ...
> library live at fixed addresses within the virtual address space,
> and the locations of same are set to absolute values within the
> program using them.  At runtime, the executable is loaded normally,
> and calls to the shared library routines depend on the routines
> living where they are supposed to (they *better* be there).
> Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy

Having written a SVr3 graphics shared lib, I believe that Conor is positing
that since the shared lib_s.a at ld(1) time will have more symbols it will
take longer to load that the normal lib.a.  I have not found this to be the
case.  Because the lib_s.a is *much* less in size, ld(1) has less object code
to read (and re-read...) than with lib.a.  I have found that a 2X size reduction
is *much* faster and well worth the additional symbols the loader must crunch.

Program initialization, (contrary to Mr. Friedl), will initialize all *external*
symbols within the lib_s (living at a fixed virtual address.)  This time is
usually small.  However, the entire shared library data section is private
to each process using the library and must be paged in as normal.  This will
almost always dominate initialization time, although it should be no slower
than normal data section loads.

At runtime all shared library calls and all externals used/called by the
shared library itself will have one extra level of indirection.  This will
slow them down by whatever that extra indirect costs on your host.

-- 
David F. Carlson, Micropen, Inc.
micropen!dave at ee.rochester.edu

"The faster I go, the behinder I get." --Lewis Carroll