kdeinit optimization

[Karl Vogel]

On 05 Jul 2004, you wrote in gmane.comp.kde.devel.optimize:

>> 1) Pre fork
>>
>> If I'm not mistaken, kdeinit will currently fork() and then dlopen
>> the app when a user launches an app.
>>
>> I'm wondering if there would be any benefit in pre-forking kdeinit
>> and then having it wait on a pipe to get the app name which is then
>> dlopen'ed. That way the VMA/fork setup of the process is done before
>> the actual startup of a process.
> 
> I don't think VMA/fork is the bottleneck, is it?

I haven't done any measures... and on Linux I doubt it.. but isn't
process forking on the BSD's more costly?!

Hell, maybe all this kdeinit stuff isn't necessary anymore with a recent
Linux kernel + prelink. If I'm not mistaken, the biggest issue in the past 
was the link relocation phase at startup, which should be pretty minimal 
with a prelink'ed system.

>> 2) Re-exec
>>
>> Another thing I'm wondering about... should kdeinit have a way to
>> re-exec?! Since a few systems are now using prelink, long running
>> KDE apps will have their sharedlibs deleted by prelink, ie. my
>> kdeinit shows:
> 
> I think that's typical for a workstation used for KDE development, but
> does that happen in other situations as well?

Well this system isn't used for KDE development, so I guess your assumption 
is incorrect :-)

And with FreeNX or LTSP, I can imagine sessions can last very long, no?