active boot time traces, some time later..

[Marco Martin]

Hi all,

i re-did some of the traces with massif and callgrind of the plasma-device 
starting up.
i have them at:
http://www.notmart.org/activeProfiling/

--------------------------------------------
Memory:
now the apps grid and the activities other then the running one are loaded 
only on demand, this has decreased boot time a lot but also memory consumption 
at startup:
http://wstaw.org/m/2011/11/22/plasma-desktopeF6619.png
after the lazyification of the top menu and a second activity is opened:
http://wstaw.org/m/2011/11/22/plasma-desktopZq6619.png

if as i suspect the typical usage workflow will be using not many activities, 
(even having hundreds of them, but not going to change to a new activity every 
2 minutes) should save not only the memory at boot, but in general for the 
whole execution, later we could even do a garbage collector for the activities 
that are not used since some time in the same session.

a thing that comes out of those numbers is that there is a *lot* of data for 
images: those are the wallpapers and the svg based plasma theme, around 20 mb 
and is not much avoidable if one wants pretty images ;) another thing that is 
to be noted, starting new activities doesn't increase too much the memory for 
images (assuming there aren't a billion widgets loaded into those activities)

what really adds up is that memory taken by the "small stuff" i suspect it's 
the myriad of qobjects created by qml, this also isn't much avoidable apart 
the usual remembering that for an ui the less widgets and thinghies around are 
there, the better it is (so, more elegance, less memory used, what one could 
desire more? ;)


-----------------------------------------------
Startup time:
well, not really time per se but the relative time the various pieces of the 
code takes, some weeks ago before the lazy-ification it was this:

http://wstaw.org/m/2011/11/22/plasma-desktopob6619.png

a lot of time taken by setupHomeScreen(), so the initialization of the qml 
elements in the corona outside of the containments, so the side panels and the 
top panel with the icon grid in it. the layout restoring of corona was very 
high (and stiull is, even if less because only a single activity is restored 
on boot now, more on that later). last thing on the picture, the big time on 
the event loop is good (i think) it's were we want it.

now looks like this:

http://wstaw.org/m/2011/11/22/plasma-desktopzS6619.png

the homescreen qml initialization gone dramatically down, it's being done 
instead in moments less noticeable.

what now really sticks out is the corona layout restore: byt not the main 
activities, that is very low actually, it's two unsuspectable things:

the windowstrip applet and the clock applet! things that i wouldn't be 
surprised right now are affecting a lot plasma desktop as well.

the window strip applet (i think) because of the use of libtaskmanager, that 
thing is really an offender in so many ways, i'll try to make its qml a bit 
more light but there is so much we can do about it.. good news, a kwin effect 
to replace it is on the way and this should make everything much faster, in 
loading and painting (the bad news is that with so many changes we have to 
cope already, there is no way on earth is going to make it for active two ;)


the clock... that one is very bad as well and takes time in mostly two things: 
instantiating the calendar (so still there even if the popup is disabled) and 
restoring of the configuration (clockconfigchanged)
so hopefully something can be inproved in the loading of the clock.

just one final remark to *really* notice how much those two widget take to 
start up, if you remove them from the plasma-device-appletsrc, then (at least 
on powerful hardware) the startup of plasma-device is simply *instant* ;)


Cheers,
Marco Martin