Toolview Slugginess

Manuel Breugelmans mbr.nxi at
Tue Jul 1 12:33:58 UTC 2008

On Monday 30 June 2008 23:27:47 Andreas Pakulat wrote:
> On 30.06.08 20:03:57, Manuel Breugelmans wrote:
> > Since the test-runner plugins are currently not responsive at all, I have
> > been looking a bit into performance. Couldnt find much though. Funny
> > thing is that when run standalone it is very snappy.
> >
> > couple of numbers [execution time of kdevelop's QTest suite]
> > ctest:               9s
> > veritas standalone:  9s
> > veritas in kdev4:   13s !?
> >
> > Thats way too much. When resizing the runner view it lags behind on the
> > cursor, the standalone one follows swift. Same thing when expanding tree
> > view items.
> >
> > An educated guess, anyone? They are using the same shared library which
> > basicly contains evrything (so cant be compiler flag related imo).
> Are they also using the same gui code? i.e. the same treeview and
> treeview-settings?
> We have similar performance problems with the treeview (opening nodes)
> and the outputview (when much output is added at once, for example make
> install for kdevplatform). But unfortunately I seem to either be unable
> to read the callgrind output I have, or the parsing of cmake projects is
> soo much worse that I can't find useful information in it.
> Andreas

Yes, the treeviews and models are the same. I've dragged both the standalone 
runner & integrated one through callgrind. The difference is 
KXmlGuiWindow+KMainwindow versus just QMainWindow being used in standalone.

If I interpret the kcachegrind's visualization
correctly, 'paintSiblingRecursive' is being called about 10 times as much in 
the KXmlGuiWindow version ... for similar actions: resizing the view a couple 
of times (and equal number of calls to QApplication::notify() ). Looks like 
upstream bug to me, marking as WONTFIX ;)

Callgrind dumps are uploaded here, ~2MB ->
[In case anyone more knowledgeable feels like looking at this]


More information about the KDevelop-devel mailing list