[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:       Mario Weilguni <mweilguni () sime ! com>
Date:       1999-12-26 12:49:59
[Download RAW message or body]

Am Son, 26 Dez 1999 schrieb Waldo Bastian:
> On Sun, 26 Dec 1999, you wrote:
(...)
> 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 

This is  really interesting, on my system it looks like this:
mario@loki:~/src/KDE/2.0/kdebase  LD_DEBUG=statistics kedit
28894:                   number of relocations: 14000


Do you have any idea why this number is so much smaller?

> 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++)

a.out libraries can do that. Not that I want to say that we should go back to
a.out :-)

I know there is already worked on this relocation problem. I was in contact
with the person doing this, however, he was very unhelpfull when I mentioned
KDE (you know, "C++ is wrong" and such - sounds familiar?), so we can not
expect help from him.

I think there will come a solution to this, but this will take some time.

> 
> 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!)

You forgot "killall -1kinit" to restart the various helper programs, when
configuration changes, similar to inetd. And you forgot the huge advantage of
this: shared memory can be used, e.g. for caching information 

Ciao,
	Mario

-- 
Gute Nachricht: Windows 98 ist kompatibel. 
Die besten Experten suchen noch zu was eigentlich.

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