shared libraries [ab]use [LWN.net]

shared libraries [ab]use

Posted Aug 5, 2005 1:51 UTC (Fri) by hp (subscriber, #5220)
In reply to: shared libraries [ab]use by dann
Parent article: Our bloat problem

Those specific ones must be gnome-vfs then, for https and authentication.

It's simple enough to cut down library deps for certain apps, but I doubt it makes much real performance difference. (unused code isn't mapped anyway)

Maybe it does, but that's why real data is needed.

(Log in to post comments)

shared libraries [ab]use

Posted Aug 5, 2005 20:25 UTC (Fri) by hp (subscriber, #5220) [Link]

Avoiding anything "not free" isn't a useful guideline.

The question is what are the tradeoffs. In the shared lib case, for example, avoiding them often means efficiency loss:
- more code running total considering all apps
- each self-implemented version of the code is slower and buggier
than a highly polished common version

Not to mention downsides such as security updates (you want to download libpng, or every single app using libpng?), bugs, lack of features, longer development time.

So if shared libs aren't a significant percentage of the overall problem, then "not free" is irrelevant; if they are a significant percentage of the overall problem then "not free" is probably more an argument for fixing shared libs (or coming up with some less-broken module system than ELF shared libs) rather than an argument for static linking and hand-rolled broken code.

Simplistic answers like "just don't use libs" are not useful. You don't want to warp the UI and implementation of every app in extensive ways just to work around a module system that needs optimizing.

shared libraries [ab]use

Posted Aug 7, 2005 20:45 UTC (Sun) by oak (guest, #2786) [Link]

I think the argument was that each *redundant* (unused) shared library
linked to the binary has a cost.

For example: Just by linking a library (that your program doesn't use),
you've increased your program's memory usage by at least 4KB. At least one
private (non-read-only) page is reserved for symbol resolving of each
linked shared library.

The new linker has a command line option to not to link dynamically
libraries that are not used. I think it was discussed on the Gnome
mailing lists, but globally enabling it had broken some program, so it's
not enabled by default.

shared libraries [ab]use

Posted Aug 5, 2005 16:38 UTC (Fri) by dann (subscriber, #11621) [Link]

Well, using lots of shared libraries affects the startup time.
Here's an example:

echo 'int main (void) {return 0;}' > t.c
gcc t.c
LD_DEBUG=statistics ./a.out 14237:
14237: runtime linker statistics:
14237: total startup time in dynamic loader: 550907 clock cycles
14237: time needed for relocation: 250684 clock cycles (45.5%)
14237: number of relocations: 99
14237: number of relocations from cache: 5
14237: number of relative relocations: 0
14237: time needed to load objects: 158487 clock cycles (28.7%)
14237:
14237: runtime linker statistics:
14237: final number of relocations: 100
14237: final number of relocations from cache: 5

gcc t.c -lgnomevfs-2
env LD_DEBUG=statistics ./a.out
14253:
14253: runtime linker statistics:
14253: total startup time in dynamic loader: 14162855 clock cycles
14253: time needed for relocation: 10427627 clock cycles (73.6%)
14253: number of relocations: 1757
14253: number of relocations from cache: 2501
14253: number of relative relocations: 0
14253: time needed to load objects: 3357732 clock cycles (23.7%)
14253:
14253: runtime linker statistics:
14253: final number of relocations: 1793
14253: final number of relocations from cache: 2501
(this is on a 2.8GHz P4)

Obviously the above is only a small part of the startup time.
Creating and maintaing the page tables, running _init for each .so,
etc etc are other parts.

Maybe a kernel person can tell us what are the kernel overheads from having lots of shared libraries...