mbr.nxi at gmail.com
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
> 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.
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