shared libraries [ab]use
shared libraries [ab]use
Posted Aug 4, 2005 19:33 UTC (Thu) by hp (guest, #5220)In reply to: shared libraries [ab]use by dann
Parent article: Our bloat problem
The talk about the clock is sort of bogus; the clock isn't just a clock, it's a small evolution frontend with all the calendar stuff in there. Those deps are coming from libedataserver (the evo backend)
The size of the calendar on the screen is small but it still has to have the same data available as a full calendar app and be able to talk to calendar servers and all that crap.
Posted Aug 4, 2005 22:16 UTC (Thu)
by dann (guest, #11621)
[Link] (5 responses)
Posted Aug 5, 2005 1:51 UTC (Fri)
by hp (guest, #5220)
[Link] (4 responses)
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.
Posted Aug 5, 2005 13:11 UTC (Fri)
by dmantione (guest, #4640)
[Link] (2 responses)
Posted Aug 5, 2005 20:25 UTC (Fri)
by hp (guest, #5220)
[Link] (1 responses)
The question is what are the tradeoffs. In the shared lib case, for example, avoiding them often means efficiency loss:
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.
Posted Aug 7, 2005 20:45 UTC (Sun)
by oak (guest, #2786)
[Link]
Posted Aug 5, 2005 16:38 UTC (Fri)
by dann (guest, #11621)
[Link]
echo 'int main (void) {return 0;}' > t.c
gcc t.c -lgnomevfs-2
Obviously the above is only a small part of the startup time.
Maybe a kernel person can tell us what are the kernel overheads from having lots of shared libraries...
Posted Aug 6, 2005 17:59 UTC (Sat)
by rlrevell (guest, #23596)
[Link] (1 responses)
Right clicking only lets me "Copy Date", "Copy Time", "Adjust Date & Time" or set the "Preferences".
Left clicking brings up a view of the current month, that only lets me scroll back and forth to select a different day and month. AFAICT there's nothing you can DO with it.
Are you sure you did not mean "in the FUTURE this will provide access to evolution calendaring functionality?"
Posted Aug 7, 2005 1:02 UTC (Sun)
by hp (guest, #5220)
[Link]
Posted Aug 12, 2005 23:53 UTC (Fri)
by dag- (guest, #30207)
[Link]
OK, ignore the clock then, let's look at any other applet, just as an example:shared libraries [ab]use
ldd /usr/libexec/null_applet | wc -l
63
and it does link to the krb, ssl, gss*, gnome-keyring libraries (this seems
to be true for all the applets that I have tried, and in general all the Gnome applications seem to link to a huge number of libraries).
Those specific ones must be gnome-vfs then, for https and authentication.shared libraries [ab]use
No, that's the wrong assumption. Shared libraries are less expensive than shared libraries [ab]use
statically linked ones, but not free.
Avoiding anything "not free" isn't a useful guideline.shared libraries [ab]use
- 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.
I think the argument was that each *redundant* (unused) shared library shared libraries [ab]use
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.
Well, using lots of shared libraries affects the startup time. shared libraries [ab]use
Here's an example:
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
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)
Creating and maintaing the page tables, running _init for each .so,
etc etc are other parts.
Heh, really? It doesn't do any of that fancy stuff for me.shared libraries [ab]use
It has a read-only display of your evolution calendar and todo list, if you haven't put anything into evolution then you won't see anything.shared libraries [ab]use
Every Gnome user interested in a clock was secretly running a complete evolution client ? I don't think this is funny. Really. Who's bright idea was this ? And everybody agreed to that ?shared libraries [ab]use