GNOME Bugzilla – Bug 96879
vte causes severe loading of X server
Last modified: 2006-03-06 00:40:18 UTC
The gnome-terminal that comes with RH 8.0 can cause the X server to use 50% of the CPU on a 2Ghz pentium. The gnome-terminal that was in RH 7.2 did not have this problem. To reproduce the problem, fire up a gnome-terminal and then run a curses application inside it that does a fair amount of real-time screen updating. One such application is available at http://linuxtrade.0catch.com (which is a program I authored). I like to use a gnome-terminal with 160 columns and 60 or so lines. With the new gnome-terminal font selector,I had to use the 8 point monospace font to get that many lines/columns on the screen. Then, just display 30-40 stocks during the trading day. That will generate a fair amount of screen updating (but no scrolling). Then, use the "top" command and you will see that the X server is consuming vaste quantities of CPU. Repeat the experiment with plain "xterm" or the gnome-terminal from Redhat 7.2, and you will find that the CPU usage is almost negligible. Another way to reproduce this bug is to simply fire up two gnome-terminals. Run "top" in one of them, run "vi /etc/termcap" in the other. In the "vi" window, repeatedly press ctrl-u ctrl-d ctrl-u ctrl-d .... In other words, simply scroll the display up and down. Even at the slow speed you can type those two vi commands, you can drive the X server to 50% CPU utilization (2Ghz P4). This really is a terrible regression and renders the gnome-terminal unusable. I have recommended to all of my friends and coworkers to stay with Redhat 7.3 until this problem is corrected. Something went seriously wrong with the testing process on the RH 8.0 release.
*** Bug 98560 has been marked as a duplicate of this bug. ***
Likely related to 98560 - slowness could be because vte is cpu bound. I'm going to mark it a dupe of this bug to create a common place for vte performance bugs.
As another note, scrolling using vte seems to peg the CPU at 100%
*** Bug 89507 has been marked as a duplicate of this bug. ***
bug 60972 is related, but discusses at network usage
I'm seeing this behavior too; gnome-terminal compiled with vte is really unusable (for me anyway) - scrolling speed is too slow and the terminal is generally unresponsive. Gnome-terminal works fine when compiled with zvt. I think that the severity of this bug should be greater than 'normal' - having a good-performing terminal is very important. Let me know if I can provide any more info.
I tried recompiling gnome-terminal with zvt but it exhibited the same slowness (high CPU utilization, etc.) when scrolling. I also tried compiling the latest gnome-terminal (2.1.2) and the latest vte (0.10.7), which didn't seem to improve things either. Has anybody come up with a good workaround yet? I am on an IBM T30 laptop with a Radeon 7500, so unfortunately there's no acceleration available. I just don't understand how gnome-terminal could be performing so much worse now than it did in RedHat 7.x. I agree with the previous poster that the severity should be higher than "normal". The problem is so pervasive that you encounter it extremely frequently.
The workaround is to do the following: mkdir $HOME/.fonts cd $HOME/.fonts cp /usr/X11R6/lib/X11/fonts/misc/6x13.pcf.gz . # for 1024x768 cp /usr/X11R6/lib/X11/fonts/misc/7x14.pcf.gz . # for 1280x1024 gunzip *.pcf.gz #N.B. only unzip one of those fonts at a time Now close down all gnome-terminals. Then start a new gnome-terminal and change the font to "fixed". This is strictly a workaround. The terminal will lose the ability to display bold text. But it will scroll much faster. Not to mention that the font is more readable than any of the scaled fonts. -Rick
Even that doesn't work for me, other than the fact that I like the font better. I still get the slow scrolling, it doesn't seem improved at all. Maybe you just need an accelerated driver in order to get rid of the problem completely. :(
That workaround does work for me as long as my terminal window isn't maximized; when the window is maximized, the problem still exists. I'm currently using redhat phoebe-3. gnome-terminal-2.1.3-2 vte-0.10.8-1
A little more info: The above workaround does speed up scrolling for me (when the window is small anyway) but the CPU usage is still very high (around 100%).
I observe this with gnome-terminal 2.2.1 and vte 0.10.26. I do ncurses-managed text scrolling in a big 80x32 window. The antialiased font for the current profile is Monospace 14, whatever that is. Scrolling with line-at-a-time keys is slower than my key repeat rate, and the X server takes up to 95% CPU.
Havoc mentioned that this is fixed in their internal tree, but I think it hasn't been published publically yet. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85874
*** Bug 105463 has been marked as a duplicate of this bug. ***
Nalin, any idea what might be causing the slowdown? its there in vte .11.10. This problem is annoying and renders the gnome-terminal unusable on solaris. I have observed that gnome-terminal is twice as fast as xterm on linux (Xfree86) but 10-15 times slower than xterm on solaris 2.6(native X). This was with famous '/bin/ls -R' done repeatedly and averaged. Cache doesn't seem to affect the result because most time is spent in scrolling and I think looking at other bugs, vte is really bad at scrolling. Are we still drawing one character at a time instead of a line at a time?
> I have observed that gnome-terminal is twice as fast as xterm on linux > (Xfree86) but 10-15 times slower than xterm on solaris 2.6(native X). This is not true. gnome-terminal with vte is far slower than xterm in Linux too depending on your video card. I'm afraid it was only optimized and tested by developers using high end video cards.
Well, my g-t is built with latest vte both on solaris 2.6 and linux. And same test with same video card, done for xterm and g-t gave me above result. I would assume even on a different card but same OS, relative speed between xterm and vte won't vary. Anybody got any clue why vte sucks big time on solaris? any workarounds?
Linux and Solaris use VERY different X servers, so having the same video card on both operating systems is not a good control variable. The cause of vte slowness in Linux seems to be on certain video cards (but not all), AA fonts causes extreme slowness while it goes very fast on certain other video cards.
check out bug #122656
Created attachment 20229 [details] [review] xft patch to count the number of glyphs drawn -- for profiling
I added the lines in the above patch to Xft and then ran gnome-terminal and xterm (using xft) and compared the number of glyphs drawn. When simply catting a large file, gnome-terminal draws fewer glyphs than xterm. But for other common operations, for example, scrolling through a file in vim, gnome-terminal draws *far* more glyphs. I ran each terminal at 80x25, opened the Xft ./configure file in vim ("vim configure"), and scrolled down to line 300 by holding down ctrl-E. Number of glyphs drawn: xterm: 10178 gnome-terminal: 411463 So, I think it's pretty clear that there's lots of room for improvement. Finding it might not be as easy as showing that it exists, of course. :-)
The profile information in bug 137864 might be helpful (look at the attached files there)
FWIW, I've found the cause of Noah's discovery, and am working on fixing it. What's hapenning is that currently vte keeps a bounding box of all updates, and invalidates (aka updates) that bounding box. This means, when you move your cursor in vim, the rectangle including the cursor and the part of the status bar that shows cursor location is updated. That's about half of the screen on average. *** This bug has been marked as a duplicate of 161342 ***