Review Request: startup faster; don't wait for kwin or kcm's in ksmserver

[Lubos Lunak]

On Saturday 07 of November 2009, Sebastian Sauer wrote:
> > On 2009-11-04 10:10:06, Lubos Lunak wrote:
> > > The reason for waiting for the WM to finish setup is not the fallback,
> > > but making sure the WM is ready. There are some aspects related to
> > > window management where applications just read the status during their
> > > startup and don't update later. So waiting for the WM ensures this is
> > > set up properly before other applications may read that (although,
> > > thinking of that, this is currently a bit broken anyway, as KWin lets
> > > ksmserver continue a bit too soon).
> > >
> > > The second case is something similar. The kcminit modules do various
> > > setup and it is a question if it is ok to let normal apps start while
> > > this is still taking place.
>
> Specs are relative. Cold start (not initial) takes up to 9 seconds till the
> plasma desktop is visible / ksplashx closes.

 Hmm. Twice 1/2s is not that insignificant then :-/.

> The thing is that the wm starts very early. Even before plasma which does
> not need the wm at this point. The first "real" applications are rather
> late started/restored. Maybe we should just wait in
> KSMServer::autoStart1Done() till the wm is ready? Would that be enough?

 Plasma is not different from other applications in this regard, in fact, it 
may depend more on it - compositing status, number of virtual desktops, etc. 
I have no idea what would happen if e.g. Plasma thought there was just 1 
virtual desktop because it saw that too soon.

> The kde startup process has lot of potential for optimizations.

 It is intentionally designed that way. The original application launching 
code (around KSMServer::tryRestoreNext()) is written to launch apps one by 
one. IIRC the reason for that was that computers[*] of those days were bad at 
handling the load and putting sleeps here and there actually improved the 
overall situation. I doubt anyone has benchmarked this in a reasonably recent 
time.

[*] Or maybe we could blame the kernel.

> Time 
> expensive things like e.g. kcminit are atm blocking the whole startup. Long
> term we need to have expensive things run in parallel at startup. Anyway,
> if you think that this is not a good idea then it should be maybe done
> another way.

 I don't know if there is another way. The code can be changed to launch 
normal apps in parallel if that helps, there would be no problem with that. 
But the rest currently has certain ordering (see ksmserver/README) with some 
implications. For example startup phase 0 (i.e. Plasma) is done quite early 
and waited for completion in order to have the desktop ready, hide the splash 
and give the impression that the desktop or more or less ready while normal 
apps are still being loaded. Moving things one way can mean the splash is 
shown needlessly long when the desktop could be already usable, opposite way 
would be showing desktop that is still not usable (as is the case with some 
Windows versions and AFAIK it's rather annoying).

 If you would have some time to spend on this, it would be interesting if you 
could analyze the KDE startup as a whole and see where the time is spent 
(note: cold vs warm disk caches did tripple the number when I tested that the 
last time, so pay attention to that). With that thinking about doing some 
rearranging should be simpler.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 084 672
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz