glib dependancy in KDE3.x

[Waldo Bastian]

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.

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com