Linked by Eugenia Loli on Tue 30th Sep 2003 05:20 UTC
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
More News »
Sponsored Links



This is getting really boring.
You see, if you know everything oh so perfectly well, then
a) why don't you tell the Freedesktop people about it. Apparently they're so stupid that they could really need your help!
b) why don't *you* do something? Why don't *you* check out the source to one of those libraries you claim are so uberslow [1] and actually fix it instead of whining and generally getting on everybody's nerve?
Not that the 2 functions would hurt, no the loading of these libraries do, specially under heavy load.
This might actually be valid criticism of the way dynamic library loading works on Linux-based systems. However, the solution is *not* axing libraries - that's something you could do in a top-down mandated environment, i.e. a proprietary operating system. However, it will never work in an open source environment.
This doesn't mean architectural improvements aren't possible. For example, one could try to improve sharing of dynamic libraries between adress spaces/processes (i.e. basically what the kdeinit hack does, but on a system-wide level).
There are two ways I believe this can be done:
a) implement library loading in the kernel
b) implement library loading in a system-wide dynamic library daemon; whenever an application needs to load a library, it contacts that daemon, which will load the library (if it hasn't already been loaded), relocates its symbols and provides a read-only mmap to the fully relocated library to the client application.
Has anyone ever made a real life test of GNOME or KDE under heavy load ? E.g. when copying big files across the harddisk.
Actually, yes, and interactive apps can come to a crawl when copying big files across partitions. That's mainly a kernel/scheduler problem, though. You'll notice that advanced console apps are affected by latency/responsiveness issues in that case, too.
[1] Yes, apparently there *are* some libraries using horribly inefficient algorithms out there. But in most cases, those libraries are able to survive because there's no alternative - and it's generally better to have *something* that works (even if it's slow) than to have nothing at all.