[patch] Preload popup menus for the desktop (3.5)
wheeler at kde.org
Tue Apr 4 22:53:02 BST 2006
On Tuesday 04 April 2006 20:03, David Faure wrote:
> Interesting; so finding and loading plugins is what's slow, rather than
> config file parsing... But how many plugin do you get there? I thought we
> only had a few: kuick, ark, akregator. That's all I get when doing
> "ktradertest KonqPopupMenu/Plugin".
I also get the same three and they're pretty consistently around 40 ms each
> Oh, so it's the plugin code that's slow, not the dlopen stuff? Hmm, well,
> symbols are looked up on demand iirc so it's probably hard to distinguish
> the two; iirc setting LD_BIND_NOW=true forces all symbols to be resolved
> right away, this might be a way to find out.
The dlopen isn't insignificant, but it's only happening once per library (from
what I can tell), so it disappears quickly in the profiling (total time of
about 50 ms even after dozens of menus are generated).
> Could it be that it's one of the above three plugins that has lots of
> "startup" code? I only had a look at kuick's code and it looks... quick :)
It's pretty consistant here -- give or take a few ms -- between the three
> Yes; I first thought we could just use another parent object; but in fact
> we can't, the popupmenu plugins certainly need to know the popupmenu into
> which they're plugging their stuff,
Yep, I tried that too. Boom. ;-)
> so they can't possibly be cached,
> unless the whole popupmenu is reused... which was your initial idea; but
> which still strikes me as a large use of memory, potentially (there are
> many mimetypes, one might end up with a very large number of popupmenus
> cached, except if using QCache...)
In my original patch I did use a QCache, though I was doing things per item.
We could probably save a bit more doing one menu per mime type.
> Presumably there's substantial time spent in the KSimpleConfig creation on
> 675, no?
Nope. 1-2 ms here. (I have that whole if block in one profile block and I
did check to make sure it's being hit.)
The other two blocks of significance here are the one starting with:
QStringList dirs = KGlobal::dirs()->findDirs( "data",
...and the following large for loop -- that varies a lot, presumably based on
whether or not DCOP calls are used. Here it's often as little as 20% and as
much as 60%. That's another area I want to look at more closely.
The next one starts with:
The if block there is about 10% of the total time, but presumably that can
also be cached in the way that the other KTrader offers list is.
The world is full of magical things patiently waiting for our wits to grow
More information about the kde-core-devel