Behdad Esfahbod's daily notes on GNOME, Pango, Fedora, Persian Computing, Bob Dylan, and Dan Bern!

My Photo
Name:
Location: Toronto, Ontario, Canada

Ask Google.

Contact info
Google
Hacker Emblem Become a Friend of GNOME I Power Blogger
follow me on Twitter
Archives
July 2003
August 2003
October 2003
November 2003
December 2003
March 2004
April 2004
May 2004
July 2004
August 2004
September 2004
November 2004
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
October 2008
November 2008
December 2008
January 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
November 2009
December 2009
March 2010
April 2010
May 2010
June 2010
July 2010
October 2010
November 2010
April 2011
May 2011
August 2011
September 2011
October 2011
November 2011
November 2012
June 2013
January 2014
May 2015
Current Posts
McEs, A Hacker Life
Thursday, October 13, 2005
 gnome-terminal performance

[Somehow I managed to not write here for quite a while. In the meanwhile, I passed another birthday. Twenty-three now.]

That gnome-terminal is damn slow is not news, but I found a silly simple test case to measure how things are going. The test case:

time for x in `seq 10000`; do echo {a,b,c,d,e}{A,B,C,D,E}; done

With no write at all (>/dev/null):

real 0m1.436s
user 0m1.428s
sys 0m0.004s

with xterm (80x46, 10x20 bitmap font):

real 0m5.282s
user 0m1.384s
sys 0m0.032s

with xterm minimized (same settings):

real 0m4.472s
user 0m1.652s
sys 0m0.088s

with gnome-terminal (80x46, same visual size as 10x20, Bitstream Vera Sans Mono 12):

real 0m23.708s
user 0m1.388s
sys 0m0.048s

with gnome-terminal minimized (same settings):

real 0m2.833s
user 0m1.800s
sys 0m0.068s

To test the minimized case, just do a sleep 3 before the line and minimize the window after pressing enter.

Now that gives something to optimize for! Note how gnome-terminal's pseudo-terminal emulation is in fact faster than xterm's, since when minimized, g-t is faster. All we need is a hero to rip off some 50% of that rendering time to start with...

Update:

with gnome-terminal (80x46, 10x20 bitmap font):

real 0m4.126s
user 0m1.848s
sys 0m0.088s

with xterm using xft (same Bitstream Vera Sans Mono 12, run by uxterm -fa 'Bitstream Vera Sans Mono' -fs 12):

real 0m27.334s
user 0m1.444s
sys 0m0.036s

Moreover, if I resize the windows to 80x4:

with gnome-terminal (Bitstream...):

real 0m7.480s
user 0m1.884s
sys 0m0.088s

with xterm using xft (Bitstream...):

real 0m26.638s
user 0m1.408s
sys 0m0.024s

Observations:
Something funny that I experienced during these tests: My laptop's CPU would get to 70C and automatically drop the frequency to 1.2GHz (from 2.4GHz.) Thanks to the CPU Frequency Scaling Monitor applet, I figured that out, instead or reporting bogus digits. In the mean time, flipped the Vaio on the table such that it gets some more air. Have to open it for cleanup again, but it's really showing its age. Needs another backlight too. After getting a new laptop, I may use the old one for some Wacky laptop tricks.

Comments:
I've seen big improvements in gnome-terminal in the latest Fedoras. Your test on my FC4-system gives very different results.

xterm:
real 0m33.701s
user 0m1.668s
sys 0m4.532s

gnome-terminal:
real 0m10.579s
user 0m1.952s
sys 0m0.480s
 
For me on a Ubuntu Breezy system it's like that:

gnome-terminal:
real 0m9.182s
user 0m1.325s
sys 0m0.051s

xterm:
real 0m2.067s
user 0m1.238s
sys 0m0.032s
 
Hopefully it will get faster with Federico's Pango optimisations (a side effect of speeding up GTK+).
 
I submitted a patch a while ago that optimizes GtkRange, so that the scrollbar is only redrawn if it really changes. This did improved the speed quite a lot.

http://bugzilla.gnome.org/show_bug.cgi?id=313991
 
I am using Federico's Pango optimization patches, and gnome-terminal performance is much improved.

gnome-terminal:
real 0m6.401s
user 0m1.072s
sys 0m0.064s

xterm:
real 0m5.520s
user 0m1.096s
sys 0m0.072s
 
Using an ugly bitmapped font makes gnome-terminal *much* faster. With xterm and gnome-terminal using the same fonts:

gnome-terminal
real 0m2.591s
user 0m0.892s
sys 0m0.048s

xterm
real 0m4.249s
user 0m1.204s
sys 0m0.024s

There is also very obvious flicker on xterm, and it's smooth on gnome-terminal.

The font I'm using is B&H Lucidia Typewriter.

When I switch gnome-terminal back to Bitstream Vera Sans Mono:

real 0m18.789s
user 0m0.956s
sys 0m0.048s

Sigh, Pango.
 
As I remember from last year that I was playing with these things, Konsole is fastest, even faster than xterm. Try it! Even now when I use gnome-terminal in GNOME, I think about good days I had in KDE...
 
use rxvt it's fast and tiny
utf8 is slower by the way

with fixed fonts :

rxvt :

real 0m3.020s
user 0m2.456s
sys 0m0.064s


gnome-terminal:

real 0m9.239s
user 0m2.108s
sys 0m0.080s


xterm :
real 0m10.565s
user 0m1.780s
sys 0m0.064s
 
I had the same problem. Turns out gnome-terminal is very slow if accessibility is enabled... go to preferences -> accessibility -> assistive technology preferences and uncheck "Enable assisteive technologies. Then it won't matter the window size. The performance will range from 0.7x - 2x speed of konqueror. Plenty fast in any case, but it's dog slow with accessibility.

I almost switched to konquerer for the terminal until I found this out.
 
Of course I meant konsole not konquerer...
 
I can report that, in 2009, gnome-terminal is still basically unusable for multi-tab development due to its speed (or lack thereof). There is an actual visible delay when switching from an editor in another tab to a bash prompt.
 
Hey,

i'm developing a library that does the same as libvte (the backend of gnome-terminal). the reason is libvte's speed-issues. the library is aimed to look as nice as gnome-terminal and be as fast as xterm. you find it at: (with a tabbed terminal using libvexterm surrounding it)

https://sourceforge.net/projects/vexterm/

it has just been released, but works quite well already.

i'm posting here to attract some attention to vexterm; i'd like to find some developers who are also interested in a faster terminal for the gnome-desktop.

i ran the test, too (on a Pentium M 1,4Ghz, 1024Mb RAM). here are the results:

gnome-terminal:
real 0m21.338s
user 0m1.080s
sys 0m0.048s

xterm:
real 0m4.960s
user 0m1.188s
sys 0m0.056s

vexterm:
real 0m3.826s
user 0m1.156s
sys 0m0.044s

greets
sebastian
 
Thanks sebastian.

Well, starting a new implementation instead of just working on the existing one to improve it is an awful idea :(. Not sure why you did that.

That said, I'm pretty sure vte is doing very well speed-wise apple-to-apples.

In your numbers:

- What version of vte are you testing?

- Are all three using the same font, same rendering?

I really doubt that they are.

Anyway, you're always welcome to start contributing to vte. Let me know.

Thanks,
behdad
 
Well this project started as a experiment about the way i'm trying to speed up rendering. i don't exactly know what vte does to improve the speed of pango-rendering (which is the bottleneck, i think), but vexterm caches single-character-pixmaps for each colour-combination and uses these to blit the whole image together.

indeed i was using the same fonts in both gnome-terminal and vexterm (it's called 'Monospace'). both's terminals appearance is exactly the same. the vte version is 0.20.0 (seems to be a little old?)

somehow it's not really apple-to-apples: by using xdrawables as cached elements, vexterm cannot support transparent background.

maybe this approach could be integrated into vte as a user-selectable alternative to the current rendering process. (of course only if it turns out to be significantly faster compared to current versions of vte...)
i think there might be users who like speed more than fancy background images.

i'd really be interested in testing libvte using a rendering/cacheing strategy as described above

greets,
sebastian
 
Yes, vte 0.20.0 is three years old.

Vte does all those kinds of caching indeed. Check vtedraw.c in vte git master branch for example.
 
perceived significant improvements in gnome-terminal in the latest Fedora. I think it gives very different results. also thank you for your contribution was of great help ...
 
Post a Comment

Links to this post:

Create a Link



<< Archive
<< Home