glib dependancy in KDE3.x

Waldo Bastian bastian at
Fri Mar 7 17:28:35 GMT 2003

On Friday 07 March 2003 17:51, Maks Orlovich wrote:
> > This page fault is handled in the kernel, where the VM decides how this
> > page can be provided. Usually, the page can be found already in the
> > "cache", which is just another way of saying that it has been loaded
> > previously, but nobody used enough other memory so that the linux kernel
> > saw the necessity to throw it out.
> <snip>
> You're grossly simplifying things here, by ignoring the effects of disk
> latency, readahead, cache pressure, linking time [1], etc. There is a
> considerable performance penalty imposed by the paging in libraries on
> demand, so I wouldn't be surprised if that changed. You're also forgetting
> that the layout of libraries is never optimal, so the RSS footprint is
> considerably larger than the actual working set. Unless something is in an
> entirely different object file section (like say the EH or debug info
> tables) I don't think you can say it has no effect.

But this is all pretty much limited to applications that link directly to 
arts, which aren't that many. I think this is much less of an issue than e.g. 
the use of libart_lgpl, which for some reason is being linked in for every 
possible KDE application.

bastian at -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at

More information about the kde-core-devel mailing list