performance tips wanted

[Maks Orlovich]

>  Aren't the menus of the toolbar built on-demand? That's bad :(. But this
> toolbar isn't enabled by default, is it?

It is, IIRC. And just doing the top-level may take plenty of time if one's 
bookmarks aren't well-organized. Plus, IIRC, it has to scale some of the 
favicons, too. 

What would really be nice if we could create the toolbar itself on demand, 
too. Creating all the toolbars takes like 100ms or something, IIRC, and we 
only show 2 of them by default. (Alternatively, QDockWindow ctor could use 
optimizing -- but that stuff is scary/complicated!)

> > Turning off background images for the iconview saves some time, too (I
> > think it was like 70ms here - scary stuff).
>
>  That's part of the 'turn off stupid eyecandy'.

Yeah, but not all of the eyecandy is going to matter performance-wise in most 
cases; and some stuff that's not really eye-candy can be slower, too. I.E. 
with styles -- for startup time, the difference between Keramik and HighColor 
is probably <5ms on my test box (Keramik does use somewhat more memory 
per-rpocess though, although typically <100K; although I do have to optimize 
the fancy bevel for the combos a bit to avoid burdening the cache for people 
using the animated combo effect). On the other hand, if you use a pixmap 
theme like Marble, it's gonna load a whole lot slower, run a whole lot 
slower, and not really look better to most people.

Also, you might find that using HighColor is faster for startup than using 
Default, although it's more eye-candish, due to the way the Qt plugin loader 
works.*

> > BTW, when do you think would be a good time to backport the kimggallery
> > and the kfmclient speed ups? 3.1.1 timeframe?*
>
>  I forgot, we probably could do that :). I know nothing about kimggallery.

It was linking in to KHTML, near certainly inadvertedly, causing it to be 
dlopen'ed on Konqueror's filemaneger profile startup, but I don't know for 
sur that that was a mistake since I don't know how the stuff that checks 
plugins for missing symbol errors works :-)


*When trying to find the plugin to open, it tries to guess the right one by 
doing a string similarity match between the internal, qt-level key for the 
plugin [like the ones qtconfig shows] and the .so name. highcolor.so and 
highcolor look quite similar; highcolor.so and "default" (or is it classic?) 
don't; so it may end up dlopen'ing wrong styles.