[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kinit: A new way to start KDE programs!
From:       Waldo Bastian <bastian () suse ! de>
Date:       1999-12-26 12:43:51
[Download RAW message or body]

On Sun, 26 Dec 1999, you wrote:
> Hi, Waldo,
>
> Nice work!  Question, though.  Did you do or consider doing a
> benchmark where all the standard libs are already linked together and
> the KDE app links against that?  What I mean is a KDE-special ".so"
> library, say "libkdecomb.so", which is a combination of the typical
> libraries used by a KDE app:  libkimgio, libjpeg, libtiff, libz,
> libpng, libqt, libX11, libm, libjscript, libkfile, libkfm,
> libkdecore, libXext, libkdeui, libstdc++, and libc (or their KRASH
> equivalents).  I would predict this would give you most of the cost
> savings of your proposal without the (huge) disadvantage you mention
> at the end of your proposal.

No, i haven't. But my understanding of the issue is that putting 
everything in one library will not give the desired advantage unless we 
have a way to prevent this libary from "relocating". Relocating 
consists of doing symbol lookups and adding offsets to addresses. Under 
Linux, libraries in general need to be relocated (That's why you need 
to compile libs with the various -PIC options). If you do an "objdump 
-syms" of a library and filter out the symbols which live in the .data 
section you will see that all 'vtables' live there. Typically all these 
vtables need to be relocated. You can start an application like e.g. 
kedit as follows: "LD_DEBUG=statistics kedit" and then you will see 
that the linker needs to do 30.000 to 40.000 relocations. (38482 in my 
case) This takes about 200ms on my computer. (This is more than the 
150ms stated in the readme, because kedit also links in libkspell, 
libkio and libkfile) This link time is very much a function of the 
number of relocations to be done and much less dependant on the number 
of libs to link.

Putting everything in one lib does not reduce the number of required 
relocations dramatically because this lib still needs to be relocated. 
One could try to make a non-relocatable library which loads to a fixed 
address but this is rather cumbersome. Not to mention that it would 
require the recompilation of libraries out of the control of KDE. (we 
can hardly provide system/compiler dependent libs like libc and 
libstdc++)

The "huge" disadvantage you mention is not _that_ huge in my opinion. 
It is still possible to identify the process based on the output of ps. 
Instead of "kedit" it now gets listed as "kinit: kedit". You just can't 
use "killall -9 kedit" but have to use "kill -9 <pid>". If you use a 
program like "ktop" this is unlikely to affect you at all. You just 
need to be aware of this when working from the shell.

As an advantage you can clean up your desktop with "killall -9 kinit" 
>;-) (Don't try this at home kids!)

Cheers,
Waldo

[prev in list] [next in list] [prev in thread] [next in thread]