[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [patch] Preload popup menus for the desktop (3.5)
From:       David Faure <faure () kde ! org>
Date:       2006-04-04 18:03:26
Message-ID: 200604042003.26876.faure () kde ! org
[Download RAW message or body]

On Tuesday 04 April 2006 12:19, Scott Wheeler wrote:
> About 35% of popup creation:
> 
> plugin = 
>  KParts::ComponentFactory::createInstanceFromLibrary<KonqPopupMenuPlugin>(
>   QFile::encodeName( (*iterator)->library() ), this,
>   (*iterator)->name().latin1() );
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".

> From what I saw tracing the calls from KParts and then to KLibLoader is that 
> it was KLibLoader::createObject() which is using up most of the time.  
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.

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

> Since  
> that's just a virtual that's implemented in the plugs that's where I stopped 
> and went back to caching.  The problem is that the second argument to the 
> above call is a QObject (the parent), which in this case is the popup being 
> created.  That naturally makes caching the call problematic.
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, 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...)

> There are a couple other areas that I could track down; I'm currently 
> instrumenting the stuff by hand so I just know "20% of KonqPopupMenu::setup() 
> is somewhere in this 20 line block of code and the other 30% is in that 
> block."
Presumably there's substantial time spent in the KSimpleConfig creation on 675, no?

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


[prev in list] [next in list] [prev in thread] [next in thread]