Re: On the cost of libraries

[Drazen Kacar <dave arsdigita com>]

Alex Larsson wrote:

> In order to compare the cost of having many libraries linked to the app i 
> also created 40 small (just 2 symbols in each) libraries that could be 
> linked in to the app.

[..]

> If i on the other hand link the small libraries before the large one i get 
> a speed difference.
> 
> Here are some results on my Athlon 700Mhz
> N libs   usecs/lookup   delta
> =============================
> 1        2.43           
> 1+10     3.98           1.55
> 1+20     6.24           2.26
> 1+30     9.62           3.38
> 1+40    12.96           3.34
> 
> As we can see, linking to 40 extra libs increased the cost of symbol 
> lookups with more than a factor of 5.

[...]

> 185 milliseconds extra startup time is noticeable, but how many apps 
> actually dereference 10000 symbols at startup? Gtk+ 2.0 with dependencies 
> currently exports about 4500 symbols, and it is concievable that the full 
> Gnome 2 API will export about 10000 symbols.

You need to make a difference between function and data symbols, since
they are handled in a different way. Data relocations must be processed
before the application gains control. Lookup for function symbols can be
deferred. Having data relocations is bad for a number of reasons.

> [...] and lower level libraries are (hopefully) linked earlier.

Like libc? No, they are usually linked in later.

> As a rough guess i think the penalty linking to 60 libraries is on the 
> order of 50 milliseconds extra startup time. I think this is something we 
> can live with.

The penalty depends on what your linker can do. No-penalty case is
something like this:

  a) outlaw run-time symbol interposition in the dependencies which were
     not marked as interposers.

  b) then ld(1) can record in which library every simbol lives.

  c) run-time linker doesn't have to search libraries in the mapping order,
     because the right library is known. (Unless there were interposers,
     but this is a fairly rare condition. Even in that case, extra
     lookup time is limitted by the number of interposers, not by the
     number of dependencies.)

  d) while we're at it, the libraries which probably won't be used can
     be marked for lazy loading (or deferred loading, or however your
     system documentation calls it). If those libraries have good enough
     API, run-time linker won't load them until needed.

> To summarize, I think our current model is good and adding libraries 
> is not a huge problem for us, although I would recommend against random 
> splitting of libraries (i.e. the 10 guppy libraries linked to by gnucash 
> might serve as a bad example).

I would strongly recommend against libraries having data which is not
accessed by functional interfaces. If there is such data, the library
must be loaded even if it will never will be used and run-time linker
must process data relocations.

And all private symbols in the libraries should be marked as such.

-- 
 .-.   .-.    Errors have been made. Others will be blamed.
(_  \ /  _)
     |
     |        dave arsdigita com