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.
Please don't mis-represent my point. I did not say that you can play games or encode OGG-files while compiling software and get good performance/responsiveness. I believe I specifically mentioned common-day activities that all of us tend to do, which includes web-browsing, e-mail checking, document creation, and other "productivity" things...I haven't tried watching movies yet, but I suspect that wouldn't be a problem, since that goes through the graphics card.
I am also not talking about a 486. That was my fault for not specifying. I'm on a 1.1GHz, 256MB RAM, 64MB GeForce 2 GTS, 19" monitor system (which I run at 2046x1536 resolution). On that particular system, I can compile and do other things fine. Those with similar systems should have similar experiences. Even on my "high-power" (though it's not really high-power anymore) system, I could not compile something and do other things productively on Windows.
I'm not talking about a 486 here. if you have a 486, you should be compiling on some other, high-power, system and then moving that over to your 486. This would be especially important for such old crappy processors, because any extra optimization would help alot.
social sciences can never use experience to verify their statemen
Some distros do. But one problem is the code that the GCC generates. Gentoo warns you to not use march=pentium4, and to use i686 instead, because pentium4 can cause bad code. I guess that older versions of GCC may have had the same problem for i686 at one point. Who knows...
Vote for global prefs bug
FYI, prelinking KDE is not easy. On Debian the QT package has OpenGL support compiled in. The OpenGL library is not prelinkable because it is not PIC (Position Independent Code). Since all KDE applications are linked to QT and thus to OpenGL indirectly, this also means that all of KDE isn't prelinkable. I don't know of any KDE app that actually uses QT's OpenGL support, so I don't know why it is compiled in. To prelink KDE I had to compile my own version of QT without OpenGL support. This works to allow prelinking, but using a a version of QT compiled with different options makes QT's style plugins not work and has other disadvantages. There are two real solutions:
- Compile OpenGL as PIC - I don't know why it isn't already.
- Compile QT without OpenGL support, and provide separate packages for people who need OpenGL support.
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.main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
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.
Why not use Konstruct instead of typing all this manually?
I don't see where this article is talking about optimizing other then self-compiling. Better read the KDE performance tips.
Enlightenment is hardly light weight now is it? I always recommend the following to those who want a faster desktop experience:
lwm
PekWM
WindowLab