[patch] Preload popup menus for the desktop (3.5)
wheeler at kde.org
Tue Apr 4 11:19:24 BST 2006
On Thursday 30 March 2006 10:04, David Faure wrote:
> I think the problem is either (or both)
> - service menus, which are .desktop files in a konq-specific directory so
> they are not pre-parsed by ksycoca
> - konqpopupmenu plugins, which are dlopened plugins (mostly from kdeaddons)
> I think pre-parsing the service menu files might be a good solution...
> ideally with a KDirWatch on the directories containing such files so that
> we notice when new files are added though.
Ok, I had some time to do some more profiling last night. About 50-60% of the
time is spent in KonqPopupMenu::addPlugins(). There the two expensive calls
About 15% of total popup creation:
plugin_offers = KTrader::self()->query( m_sMimeType.isNull() ?
QString::fromLatin1( "all/all" ) : m_sMimeType, "'KonqPopupMenu/Plugin' in
About 35% of popup creation:
QFile::encodeName( (*iterator)->library() ), this,
The first is relatively easy to cache and doing so pretty quickly took it off
of the profiling radar. The latter was more problematic.
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. 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.
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
At the moment, without changing the API, I don't see an obvious way to cache
the createInstanceFromLibrary() call. Thoughts?
Gambling: It's like a tax on people who don't understand mathematics.
More information about the kde-core-devel