GNOME Bugzilla – Bug 144085
CPU usage extremely high when lots of text scrolling
Last modified: 2004-12-22 21:47:04 UTC
When doing some operation that produces a lot of text output, eg 'cat'ing a file or a build producing reams of warnings, the combined CPU usage of gnome-terminal and X hits >90% (split 30% to g-t & 60% to X). People on various forums/articles have notices/winged about this so I guess lots of people have come across this issue. (eg comments in http://lwn.net/Articles/88161/). Some have suggested the issue is to do with AA fonts but others disagree. Perhaps a solution would be to buffer the output from the clients that are writing to the terminal and then only update the display at a certian framerate eg 30fps. Perhaps if the window is not maped to the current desktop or is wholly obscured by another window then no output is necessary and CPU use could be saved.
The rendering performance of gnome-terminal has gotten worse lately in my opinion too. When unpacking a big tgz archive (and nothing else is stressing xserver) top looks like this: 900 root 6 -10 124m 49m 77m S 78.0 4.8 134:05.23 XFree86 1306 sniff 15 0 100m 80m 16m S 12.6 7.9 2:40.44 gnome-terminal 31032 sniff 15 0 1876 452 1396 S 2.6 0.0 0:00.16 gzip 31031 sniff 16 0 2432 844 2256 R 2.3 0.1 0:00.12 tar the tar unpacking speed is actually limited by gnome-terminals ability to prosess it's output. I'm using Nvidia's binary drivers for my graphics card, hardware setup is Athlon XP 1600+, Epox 8KHA+, 1GB RAM, Geforce4 mx440. gnome-terminal is version 2.6.1.
Comparison: - In gnome-terminal (80x24) time tar -xzvf linux-2.6.7.tar.gz real 1m40.407s user 0m3.644s sys 0m2.639s - In xterm (80x24) time tar -xzvf linux-2.6.7.tar.gz real 0m24.914s user 0m3.805s sys 0m2.647s - In text mode console time tar -xzvf linux-2.6.7.tar.gz real 0m6.335s user 0m3.588s sys 0m2.525s - Output redirected to /dev/null time tar -xzvf linux-2.6.7.tar.gz > /dev/null real 0m5.692s user 0m3.564s sys 0m1.810s
Just for comparison, kde's konsole (although without AntiAlias) handle's the task even faster than xterm, in 11 seconds, and updating is completely smooth, you can't see the actual drawing take place.
Sorry for the spam, i promise this is the last one... More about the kde, in fullscreen mode and even smaller than default font, time for the above task went up from the previous 11s to only 17 seconds _with_ transparency. With gnome-terminal fullscreen/maximized, with smaller font (well actually smaller zoom level, since that results in a better quality font) and transparency, i see interesting results. Apparently the screen update rate is more CPU, than network bound (or xserver bound, effectively). I get better framerates from remote 2ghz machine over 10mbit connection, than from 1.4ghz machine run locally, the fps for these machines are 3-4 and 1-2 respectively. remote starting times weren't good either, 20seconds+ for transparent window in 1600x1200 screen. okay, that's all for me, please someone notice this \||/ ~oO~ \_U/
Please note we -are- aware of this issues. The problem is that what is needed to resolve them is much more fine grained work than cat'ing some huge file and timing it: gnome-terminal (or rather vte) needs to be run with a profiler, and the bottle necks need to be identified. There are also interations with the X server being used, as the XRender extension is being used quite intensively to render the fonts. (Btw, zooming works simply by changing the font size, so it is odd that you get better looking fonts by zooming than by changing the size ;-) )
Yeah, sorry for the spam, i just thought since this was still unconfirmed i'd post a comment to bring this up.. Oh you're right about the zoom, i must be a while ago when i tried different font sizes, fonts scale nicely now.
*** This bug has been marked as a duplicate of 137864 ***