[patch] Preload popup menus for the desktop (3.5)

[David Faure]

On Thursday 30 March 2006 04:40, Scott Wheeler wrote:
> On Thursday 30 March 2006 4:12, George Staikos wrote:
> >   What do you think the slowness is from?  If there is XMLGUI involved
> > here, I suspect the XML parsing for sure.
> 
> I'm not 100% sure (I was profiling wall-clock time by instrumenting the 
> method), but I assume it's in KTrader.  It's noticeably slower the first time 
> it's used on a given type, which would fit with KTrader caching plugins 
> (which I think I remember...).  From there it has to do service menu creation 
> and so on.

KTrader doesn't cache plugins. KTrader is only about fetching KService::Ptr objects
from ksycoca, so those are already cached, in a way. But once KLibLoader opens a 
library dynamically, it remains open, so indeed the next time it is faster to load
that plugin.

High-level caching solutions are never among my favorites, I agree with others that
we should rather try to pin down the cause of the slowness in whichever underlying
layer is slow. Also your patch is in kdesktop which doesn't solve the problem for 
konqueror, which uses the same KonqPopupMenu code.

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.

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