fun and profiling

[Marco Martin]

Hi all,

there are some things that can be evident pretty quickly with some profilers:
i ran plasma-device in valgrind, with both callgrind, to see what are the 
functions that weight more during the startup
and with massif, to see where all memory goes (said once again, avoid to even 
look at what top or system monitor say about the memory, is just misleading 
:p).

kcachegrind for callgrind and the new massif visualizer by Milian of Kdevelop 
fame can visualize it in a very very clear way, especially when there is one 
thing that eats all.

for callgrind i've loaded plasma-device with a single activity and without the 
systray containment to have something as bare as possible and to see if 
something sticks out (and yes, it does;)

at http://www.notmart.org/activeProfiling/ are the generated valgrind blurbs.

so, as timing:
* unsurprisingly, most of the time is taken by parsing qml files and creating 
the corresponding objects (like, 30% of the startup time)
* most is taken by the homescreen, in particular what's in the sliding panels: 
recommendations (not much) activity switcher and top panel (a lot)
* other offender is the window strip
* quite relevant, restoring layout by Corona
* the activity screen, even if extremely complex doesn't take much of the 
startup time, because of the way is done: it creates stuff strictly only when 
needed

if i break the homescreen qml to not load any side/top panel, the startup time 
is like 1/10 :p

The lesson that taken out of this: be lazy! :D
* big offenders are in the sliding panels: create their contents only after 
the user slides them for the first time
* corona layout restore: when plsma-device quits, always stop all the 
activities except the current one?
* as much as possible when there are big pieces of ui in qml files: if is not 
needed immediately, put it in a separate component and create it only when 
needed (luckily is very easy ;)

the panels will look empty for an instant when opened and will kinda suck, but 
the gain is really too big ;)


now: the memory:
occupied: around 40mb with panels immediately loaded, around 20 without
around half is QImage data: is not really avoidable (if we want a graphical 
application, that is :p): one third is wallpapers and the other two framesvg 
cached data (breaking svg in libplasma saves 15-20 mb of memory, everything 
looks corrupted of course)

* same consideration as before: the key is lazyness, if the panels and in 
general any needed element is created only when needed, after a fresh startup 
the memory usage is slashed by about half (not loading immediately the 
wallpapers of the other activities is quite incisive ;)

* loading less stuff in memory immediately also slashes significantly the disk 
i/o -> faster boot ;)

* if one pays attention to have as much as possible of framesvgs with the same 
size (like buttons always the same) a significant amount of data gets shared

* could also be tried delaying framesvg data loading by some seconds.. it 
would drive to have something visible before, but looking broken for a while 
(kinda loading of a site, maybe not too nice :p) but seems -really- overkill

Cheers,
Marco Martin