gdb output window performance
jens.dagerbo at swipnet.se
Thu Apr 13 01:48:12 UTC 2006
On Wednesday 12 April 2006 15:16, Vladimir Prus wrote:
> On Wednesday 12 April 2006 19:04, Andras Mantia wrote:
> > On Wednesday 12 April 2006 17:54, Vladimir Prus wrote:
> > > The call to 'scrollToBottom' was commented just now, and has no
> > > apparanent effect on performance. The 'm_gdbView' is QTextEdit.
> > > Before I go and write my own GdbLogginWidgetImplementedAsQScrollArea,
> > > maybe somebody knows any possible reason why QTextEdit is that slow?
> > Well, I'm sure QTextEdit was not designed for this purpose ("QTextEdit
> > is an advanced WYSIWYG viewer/editor supporting rich text formatting
> > using HTML-style tags..."), unless you use in LogText mode. If you are
> > already using that mode, I see no other solution, but make a faster
> > logging widget.
> Per Jens' suggestion, I've tried using:
> which has no noticable effect whatsoever. Maybe I can try disabling updates
> for the widget, so that it does not repait itself on each gdb command, but
> if that fails, I'll put together a small logging widget using QScrollArea.
> Should not be very hard ;-)
I was literary putting on my jacket as I wrote the above suggestion, so I had
no time to expand on alternatives.. ;)
I've been doing some work trying to optimize the output of a realtime logging
application based on the Windows RichText Control at work. It's also a pig
and can be really slow if used incorrectly.
The best solution I found is exactly what Alexander Neundorf suggested
elsewhere in this thread - buffer the data and push it into the QTextEdit on
fewer occasions. If it's anything like the Windows control, it's not the
painting that's slow, it's the append operation. The only solution is to do
less of them (with more data). Give it a try before making your own
More information about the KDevelop-devel