[patch] Preload popup menus for the desktop (3.5)
wheeler at kde.org
Wed Apr 5 00:42:50 BST 2006
On Wednesday 05 April 2006 1:19, David Faure wrote:
> Hmm. I can't see how the plugins would be particularly slower than the rest
> of the popupmenu-setup code, they do the same kind of thing: creating
> actions and plugging them. Although arkplugin.cpp does a new KConfig each
> time which could easily be changed to a kstatic-deleted static KConfig *
> (but you said kconfig was fast).
I don't claim to understand it, but for me it's somewhat moot since we allow
third parties to install stuff there and one poorly written service menu
entry could make Konq / KDesktop suck without any clear link between the
plugin and the sucking.
> Anyway you gave percentages in one mail and milliseconds in the next one
> so I'm a bit confused with the timing data :)
Well, the numbers that I'm getting are in ms, when I divide that by the total
I get a percentage. ;-) If you actually want to see what I'm working with
I've attached The Dirtiest Patch Ever (I'm not bothering to clean it up since
it's just hacks to get numbers out.). I've got another ugly one for
componentfactory.h, but at least with this one, if you feel so compelled, you
should be able to see if you get similar numbers. A basic guide to the
pr_setup11 / pr_setup_popupservices7 - addPlugins()
pr_setup8 - DCOP and big loop mentioned in my last mail
pr_setup9 - KTrader
pr_setup3 - KSimpleConfig
pr_addplugins2 - KTrader
pr_addplugins5 - createInstanceFromLibrary<>()
I've just been testing these with Konq since it's easier to restart quickly.
It may be true that you can't fool all the people all the time, but you can
fool enough of them to rule a large country.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 22611 bytes
Desc: not available
More information about the kde-core-devel