Speed sensation

Aaron J. Seigo aseigo at olympusproject.org
Tue Apr 15 15:33:46 CEST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 15 April 2003 01:14, Christian Esken wrote:
> Basically I removed ZoomButton including all those hideous code dealing
> with it. And the "Button Background" stuff. All that "backgound icon"
> loading and initializing and repainting in certain situations takes time.

> Due to the many options kicker provides you can find really much code in
> kicker like:
>
> if (very_special_situation && !zoomed) {
>   // do something very special here
> }

yes, i'm well aware of this ... unfortunately if we remove those featurettes, 
users will want them back. so if we start with a nice clean kicker that isn't 
burdenned down with all those features, it would only be a matter of time 
until it was again =/ the only "solution" that i see as being viable and 
practical is to optimize the features that need it as much as possible... if 
statements that compare booleans aren't expensive in UI code, so those who 
have those features turned off shouldn't be hit noticeably by the if's simply 
failing.

> And I removed "ExtensionManager::the()->initialize();" on kicker startup,
> as as it is (normally) mot needed at startup. I changed it to
> initialize-on-demand, but I know that this patch was not 100% perfect.

hrm... i don't think that would lead to much of an improvement.. 
ExtensionManager is a QObject subclass, so not much overhead as far as 
processing time goes. it is a singleton so there is only one of them around. 
the ctor is empty and initialize() isn't intensive either: it gets the global 
config, sets the group to General and does a call to KConfig::hasKey... if 
there are no Extensions to manage, it ends up calling 2 functions that 
basically no-op, as one is empty and one is wrapped in a while loop that will 
fail immediately. if there are extensions around then it does useful work. 
making it load-on-demand would likely not gain anything noticeable speed wise 
but would likely make the code more spaghetti like than it already is.

> There was some more fiddling, but I cannot remember all the details.
>
> Otherwise my kicker variant was fully compatible with kicker (embed
> applets, support all kind of extension bars and so on).

i don't suppose you still have this variant around do you? i'd be interested 
at looking at patches if only to see where speed improvements were to be 
found...

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+nGyq1rcusafx20MRAtYfAJ9yfs4tg6vkzt9iXmwJmUYSp0DYWgCeImcN
tBuLpi0gb3edhYmiRUGJ0fA=
=n56s
-----END PGP SIGNATURE-----



More information about the Kde-optimize mailing list