GNOME Bugzilla – Bug 572210
scrolling text is slow
Last modified: 2015-01-03 14:41:02 UTC
Please describe the problem: http://www.gnome.org/~davyd/gnome-2-14/ says g-t was made able to scroll /usr/share/dict/words in under a second (under 2 with anti-aliased fonts). I find that with or without anti-aliased fonts, it takes more than 3 seconds, with or without a compositing window manager. This sounds like a regression. My /usr/share/dict/words could be different, but http://martin.ankerl.com/2007/09/01/comprehensive-linux-terminal-performance-comparison/ has a reproducible benchmark which takes him .25s and takes me 2.14s. This is important because terminal scrolling speed can set an upper limit on compiling speed. Steps to reproduce: 1. open gnome-terminal 2. time cat /usr/share/dict/words Actual results: g-t takes a long time to scroll the file Expected results: g-t should take a short time to scroll the file Does this happen every time? yes Other information:
-> vte
bug 350015, bug 439247, bug 532816 and bug 572210 all look very much like addressing the same issue.
$ ls -lR --color=always > ~/ls-lR (the generated file contains 667000 lines for me) $ time cat ls-lR xterm (default 6x13 non-AA font): real 15s urxvt (default 6x13 non-AA font): real 3s vte ("Monospace 8" 6x13 AA font): real 1m51s D'oh!
I've increased the three VTE_*_TIMEOUT values in vte-private.h, hoping that by updating less often, it will be faster. It became proportionally slower instead. I've decreased those values, expecting vte to become slower, but it became faster instead. Nowhere near urxvt, but around 30s which is already a giant win. Maybe there's a bug that at most X amount of data (maybe at most one read() from the pty) is processed per visual update?
Humm. I know years ago I made vte at least as fast as xterm. Seems that it has regressed since... We need to take another look at the main loop.
Same file with a few more terminals, at roughly the same font size: pterm (putty): 10s st (suckless) 2.5s terminology (enlightenment) (aa font, blended background): 3s konsole: 5s (although hardly performs visual updates which is not nice)
We could try to just use the gdk frame clock instead of doing our own update batching.
Apparently it broke shortly after the article (linked above, in which g-t won the speed test) was written. ChPe found the culprit in bug 721944.
Vte is reasonably fast nowadays; closing.