From kde-core-devel  Tue Apr 04 21:53:02 2006
From: Scott Wheeler <wheeler () kde ! org>
Date: Tue, 04 Apr 2006 21:53:02 +0000
To: kde-core-devel
Subject: Re: [patch] Preload popup menus for the desktop (3.5)
Message-Id: <200604042353.03208.wheeler () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=114418702429983

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 
here.

> 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 
plugins.

> 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", 
"konqueror/servicemenus/" );

...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:

KTrader::OfferList offers;

if (kapp->authorizeKAction("openwith"))
{
    ...

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.

-Scott

-- 
The world is full of magical things patiently waiting for our wits to grow 
sharper. 
--Bertrand Russell