Bug 144233 - removing lines from the top of a full scrollback buffer is slow
Summary: removing lines from the top of a full scrollback buffer is slow
Status: RESOLVED WORKSFORME
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.0.1
Platform: Debian stable Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-15 01:03 UTC by David L Emerson
Modified: 2013-04-14 20:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David L Emerson 2007-04-15 01:03:12 UTC
Version:           1.0.1 (using KDE KDE 3.5.5)
Installed from:    Debian stable Packages
OS:                Linux

If I set the scrollback limit to 2000 lines, then at 1900, everything is quick and snappy.  However, once it reaches 2000, it is significantly slower.
If I reduce the limit to 500 lines, then again, when the buffer is full, things are very slow.

In fact, 1900/2000 lines is significantly quicker than 500/500.

I'm using a PII 333 MHz, so it is easy to see this slowness ;)

Proposal: rather than deleting lines one by one, delete them in chunks.  e.g. only delete when the buffer reaches 10% over the limit.
Comment 1 Peter Simonsson 2007-04-15 11:10:46 UTC
Would be nice if you could test svn trunk, you need at least rev 654139.
Comment 2 David L Emerson 2007-04-16 07:35:29 UTC
I tried with svn, 1.0.1+ #3206 (using a 1200 line buffer, and my PII 333 MHz)

While there is a slight improvement at the moment a line is added to the bottom, there is another problem that has appeared, which is much worse.

About 1.5 - 3 seconds after the bottom addition, the top line is deleted.  When this happens, there's a very annoying flicker.  It appears that the ircview is scrolled down one line (even though it's already at the bottom) and then it quickly goes back up.  It's as if the deletion of the top line causes everything to be pulled up by one line, until the total number of lines is corrected.  Actually, not all lines flicker -- just a group at the top. Sometimes only the top 8 flicker, sometimes the top 20, but I haven't seen the bottom 5 move at all.

Now, I remember there was a similar problem in a previous version (0.16 would have been the one I was using) so I had to use a miniscule 250 line buffer to keep from going insane.  Stable 1.0.1 is much better -- no flickering -- but 1.0.1+ #3206 is flickering again, although not as badly as 0.16 did.

I also noticed something else -- if I am typing when this happens, no characters appear while the deletion is being performed (which takes usually 0.5-1.5 seconds).  The key buffer is preserved, though, and the characters appear very quickly after the thing is finished.

It would be much easier to live with any/all of these annoyances if they only happened occasionally -- e.g. if 99 lines went by with no buffer deletions, it wouldn't be so bad to have the 100th cause a delay for a few seconds and a little flicker.
Comment 3 David L Emerson 2007-04-29 19:58:25 UTC
I've changed the timer to trim the scrollback once every five minutes, instead of once every second:
QTimer::singleShot(300000, this, SLOT(trimScrollBack()));
(changed 1000 to 300000)

This works beautifully for me.  I can now use konvi with a fixed-width font and 2000 lines of scrollback, and everything is smooth.  It is also *much* less processor-intensive: with deletions happening every second, the processor was getting warm enough that the fan was running continuously (it usually doesn't run at all, unless compiling. quiet laptop is nice!)  With deletions once every 5 minutes, I never hear the fan!

Further, when the deletion does occur, it doesn't seem to take any more time to process a 200-line deletion than a 1-line deletion.  In other words, I don't think this change would trigger any noticable difference on more powerful systems (except for taking more memory!)

Would it be reasonable to make this value easily-configurable?  Or just change the default to 300000?
Comment 4 Eike Hein 2007-04-29 20:18:21 UTC
> Further, when the deletion does occur, it doesn't seem to take any more time to process a 200-line deletion than a 1-line deletion.  In other words, I don't think this change would trigger any noticable difference on more powerful systems (except for taking more memory!) 

... and the scrollbar jumping around ....
Comment 5 Eike Hein 2013-04-14 20:20:46 UTC
I'm closing this now as part of our bug tracker cleanup efforts, because there are no magic performance bullets to shoot at the problem with our current text display system, and the hardware the problem was reported with is outside of our support scope. We have ambitions to replace our current text display system in the future, and will keep improved efficiency as one of the goals in mind.