The Need for Speed!

[Andrew Kar]

A lot of readers will be familiar with the great increases in speed in KDE 
3.3 / 3.4 on recent releases of Suse and Fedora Core.
Apart from the excellent work by the KDE people a lot of this increase is that 
prelinking has been merged into the kernel/linker/OS.   This is the fruition 
of work which started yonkers ago at which time KDE was aware of a speed 
bottleneck in the way that elf executables/libraries were linked which 
particularly affected C++ programs (which is why Gnomes C apps used to be 
faster). Leon Boltou did some excellent work with object prelinking which was 
quickly adopted into kde until the real solution devised byJakub Jelinek 
could be implemented at the OS level.  Anyhow that has been done and it works 
real well.

The 2nd thing that Fedora does (following standard MS windows technique)  is 
to read ahead common files so that they are are ready when needed. It does 
that in two phases 1) an early readahead that load things that the OS needs 
and a second readahead for the GUI runlevel that preloads most apps and 
libraries.

I noticed that the /etc/prelink.conf file contained a lot of junk which I 
removed as well leaving only the blacklist files and a simple;
/bin
/lib
/usr/bin/
/usr/lib/
/usr/X11R6/bin
/usr/X11R6/lib
because otherwise it would mention trees twice; it included /usr/lib/kde for 
example which is already covered by /usr/lib and who knows what effect two 
lots of prelink info with different virtual memory allocations would do.
I then ran prelink -afmhv which forces a new table and allows overlapping for 
libs that are never loaded together resulting in a much smaller virtual mem 
space.

The real killer though was the readahead file. I dont know how the Fedora team 
messed this up but I dont use any auto updates scheme at all yet this file 
was FULL of the wrong version numbers of files and libraries making it 
practically redundant.
Since I dont use Gnome and didnt want its libs and apps filling up space that 
linux could better utilise for KDE and my instant app-start gratification I 
populated the readahead rather crudely with dir listings off apps that 
started with 'k' the whole contents of /usr/lib/kde and any k* and libk* 
stuff from /usr/lib as well as any commom apps and libs that I use.
        The result of all the above after rebooting?
A desktop at least 30-40% faster although subjectively it feels at least twice 
as fast and is certainly far more responsive than XP.
For those worried about the concept of preloading, linux has always utilised 
almost ALL available memory rather than let it sit there going to waste. This 
merely forces linux to allocate it more how you want it in a more user 
efficient way rather than linux keeping it as a disk cache or whatever.
	These are the techniques windows has always used in order to achieve its 
responsiveness except windows goes even further to another method we should 
look at which is to watch how an app loads itself and its libraries and then 
restructure its on disk form for maximum load speed.

Anyhow I hope this info is of use to some of you. If your distro does not have 
readahead I see no reason why it cant be added. Prelinking is another matter 
though as AFAIK both the linker tools and the kernel need to support it. It 
is actually part of a package called kernel utilities If I recall correctly. 
Note also that KDEINIT should be disabled and not used if using prelinking. 
Both Suse and Fedora take care of this with environment variables.

-- 
regards,
andrew
___________________________________________________
This message is from the kde-linux mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.