| |||||||||||||
|
| |||||||||||||
shared libraries [ab]useshared libraries [ab]usePosted Aug 4, 2005 18:29 UTC (Thu) by dann (guest, #11621)Parent article: Our bloat problem
It seems like there's some abuse of share libraries going on.
ldd /usr/libexec/clock-applet | wc -l
Some of the libraries don't look like should be needed for a clock:
(Log in to post comments)
shared libraries [ab]use Posted Aug 4, 2005 19:33 UTC (Thu) by hp (subscriber, #5220) [Link] 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.
shared libraries [ab]use Posted Aug 4, 2005 22:16 UTC (Thu) by dann (guest, #11621) [Link] OK, ignore the clock then, let's look at any other applet, just as an example: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).
shared libraries [ab]use Posted Aug 5, 2005 1:51 UTC (Fri) by hp (subscriber, #5220) [Link] 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.
shared libraries [ab]use Posted Aug 5, 2005 13:11 UTC (Fri) by dmantione (guest, #4640) [Link] No, that's the wrong assumption. Shared libraries are less expensive thanstatically linked ones, but not free.
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:
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 librarylinked 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 (guest, #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 -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...
shared libraries [ab]use Posted Aug 6, 2005 17:59 UTC (Sat) by rlrevell (guest, #23596) [Link] Heh, really? It doesn't do any of that fancy stuff for me.
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?"
shared libraries [ab]use Posted Aug 7, 2005 1:02 UTC (Sun) by hp (subscriber, #5220) [Link] 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 Posted Aug 12, 2005 23:53 UTC (Fri) by dag- (subscriber, #30207) [Link] 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 ?
|
|
||||||||||||