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 are: About 15% of total popup creation: plugin_offers = KTrader::self()->query( m_sMimeType.isNull() ? QString::fromLatin1( "all/all" ) : m_sMimeType, "'KonqPopupMenu/Plugin' in ServiceTypes"); About 35% of popup creation: plugin = KParts::ComponentFactory::createInstanceFromLibrary( QFile::encodeName( (*iterator)->library() ), this, (*iterator)->name().latin1() ); 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 block." At the moment, without changing the API, I don't see an obvious way to cache the createInstanceFromLibrary() call. Thoughts? -Scott -- Gambling: It's like a tax on people who don't understand mathematics.