Slashdot Mirror
Optimizing KDE 3.1.x
David Lechnyr writes "This article goes into detail on optimizing KDE for speed. Typically, most distributions include pre-compiled binaries of KDE which are optimized for an Intel i386 computer. Chances are that you're running something faster than this; if so, this should help you tweak the compile process to speed things up a bit."
Gentoo does all this by default. To compile and install optimized binaries for kde, you just type "emerge kde"
Prelink is not useful anymore provided you use a recent glibc (>= 2.3) ...
This is done automatically by the libc and the dynamic linker.
the difference between a 386, 486, and pentium I-IV isn't just clockspeed and MMX, a handful of new instructions have been added. If you don't specify the arcitecture, you'll generate i386 compatable code.
so if (i == 0) i = 1234; will generate code like this:
cmp eax,0
jne L1
mov eax, 1234
L1:
A PII however, can do this:
cmp eax,0
cmove eax,1234
that might not look all that much better, but branches are a huge bubble in the pipeline, and are horrible for performance.
Do you even lift?
These aren't the 'roids you're looking for.
>I've sent emails to the debian-kde list about prelinking the >Debian KDE packages, but the maintainers didn't seem >interested. Hopefully they will eventually see the light and >start working toward prelinking KDE.
I looked at the discussion on prelinking in Debian, and it's not all such a straight forward issue.
When you have a binary, and run it, it loads all the libraries that the binary uses. When it loads the libraries, it basically puts it into memory, and then tells the binary the memory address of everything in the library. I think this is things like functions, data structures, etc.
Anyway, prelinking is when you now modify the binary, and tell it about the particular version of the libraries that it links (say version 1.0.3 or whatever) Now when you run the binary and use that particular version of the library, it loads the library into a specific memory address, and the binary already knows the memory address of all the functions and data structures.
This speeds up loading time and saves memory.
If the library version changes, then it falls back on the old method.
Now, the trouble is, when you update a library, you must update all the binaries. This means (as far as I see it) either you also update all the appropriate binaries by running prelink again on all the binaries, or you update the packages the binaries are in.
The second option would cause libraries to have huge number of dependancies, and would make minor upgrades of libraries horrendous for dial up users.
The first option has slightly more subtle problems. The problem is that it means when you update a library, it goes and unpredictably modifies binaries. This plays absolute havoc with things like tripwire, and any kind of security.
This is merely my understanding from 5 mins research, so take it as you will.