Prelinking Debian KDE - Big Problem ?
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
Reply to: