For those who haven't seen it : http://developers.slashdot.org/article.pl?sid=03/04/23/2227240 gives a pointer to an article (dated 24th.April.2003) on optimising KDE 3.1.x for i386 :
"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." The article itself is at : http://hr.uoregon.edu/davidrl/kde.html Although the main item is on generic KDE, there's an interesting bit of /. debate on the prelink-and-Debian-specific case, which I've taken the liberty of quoting here, if only for the archive value (it seems a good summary of what I see in this list's archive) : ======================================== Prelink is not useful anymore provided you use a recent glibc (>= 2.3) ... This is done automatically by the libc and the dynamic linker. ======================================== This is simply not true. Here's the truth straight from the source: glibc NEWS file [gnu.org]. It says you need "additional tools" to take advantage of prelinking, and the "prelink" program is that additional tool. I have also heard other people say that prelinking is not necessary anymore, but they were wrong. Prelinking my KDE binaries on Debian unstable resulted in a noticable startup performance increase. I hope this misinformation doesn't cause people to discount prelinking as a possible performance booster. 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: 1. Compile OpenGL as PIC - I don't know why it isn't already. 2. 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. ======================================== >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. ======================================== So .. is prelinking Debian KDE really a dead duck ? Nick Boyce Bristol, UK -- All generalizations are false
