[Kst] Performance

George Staikos staikos at kde.org
Tue Dec 23 08:13:05 CET 2003

I spent time profiling tonight, especially trying to determine the cause of 
the progressive zooming slowdown.  I'm quite certain I have found the major 
cause of this.  Funny enough, I had documented it in my visual inspection as 
a possible performance bottleneck, and kcachegrind pointed me straight to my 
comments tonight.  KstPlot::setBorders() appears to be very slow 
computationally (as opposed to in function calls).  Some of this is due to 
the for() loops which I believe can be factored out entirely.  I will hack at 
this over the holidays as time permits.

More details:  getXBorder() uses 72% as much time as KstPlot::paint(), and of 
that 72%, ALL of it is spent in setBorders().  KstPlot::paint() *should* be 
the slowest part of this code by far.  Inside KstPlot::paint(), *surprise*, 
KstPlot::setBorders is the biggest time consumer by far, even though it is 
only called 36 times while KstEquationCurve::getPoint() is called 2.4 MILLION 
times and KstVCurve::getPoint() is called 4.8 MILLION times.  Label drawing 
is still significant too, but it's much better than before my optimizations 
were applied.  Equations are too expensive (~6 times the cost) compared to 
vcurves and we should try to fix this.  log10 is called very often 
in ::paint() as well, and it might be possible to reduce or eliminate this.  
(0.41/48.6 or about 1% of ::paint() time, which is big considering that 72% 
of ::paint() is spent in setBorders() and that will hopefully disappear 
almost entirely)  AsciiSource::readField is a touch slow and hopefully can be 
improved - I haven't investigated this yet.  KstEquationCurve::FillY is very 
expensive and I see places to improve this on a quick glance.

Good news: interpolation is now fast enough to be ignored, and most of the 
slow map code is cleaned up as far as "hot spots" are concerned in demo.kst 
(only the ones in FillY seem to be significant at this point).

Regression test still passes completely, but it needs many more cases, 
including some .kst files.

George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/

More information about the Kst mailing list