On Friday 24 of September 2004 09:46, Karl Vogel wrote: > Lubos Lunak wrote in > > news:200409231854.44347.l.lunak@suse.cz: > > Which shows it's not that big improvement. The most expensive thing > > seems to > > be actually getting all the other stuff from the HDD (libraries, > > whatever). Note however that benchmarking anything with cold caches > > gives rather varying results, so the numbers are hardly exact. > > Maybe it's the SuSE patch to the ELF loader that is getting in the way > here. (ie. the MADV_WILLNEED madvise() on the exe's that causes them to be > completely paged in at startup) ?! No, setting LD_NOMADVISE=1 in order to turn it off actually seems to make things worse. > > This helps if you run a few KDE apps, since then most of the code is > already in memory.. but if you only want to run 1 app, loading all the lib > code is probably overkill. I don't think so. Modern HDDs should be able to load all KDE libs within a second at most if done sequentially, while seeking and loading only what's necessary should take more; especially given that I expect most of the kdelibs code needs to be paged in anyway. But the thing that makes the startup so long in this case is probably rather searching all the directories, for Xcursors, for fontconfig, for icons, for whatever. > > > BTW: you can look at the I/O patterns by setting /proc/sys/vm/block_dump to > 1. Then each physical disk I/O will be logged to the kernel log. Interesting, but how is one actually supposed to use it? Kernel log is saved to /var/log/messages, so if I turn it on, the log is full of messages about saving the messages. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ _______________________________________________ Kde-optimize mailing list Kde-optimize@kde.org https://mail.kde.org/mailman/listinfo/kde-optimize