GNOME versus CDE performance on SunRay

We received reports that GNOME was orders of magnitude slower than CDE on Sun Rays.

To verify and measure this, I designed and ran some performance tests in order to compare the time and bandwidth usage of GNOME (JDS) with that of CDE on Sun Rays. The tests measure the time it takes to display data using various desktop applications: Browser, StarOffice and Terminal.

I created a large (over 1MB) HTML file, containing a mix of headings, paragraphs, fixed text and images, and used it in 3 tests on a Sun Ray 100:

  1. Page through the file using the Browser
  2. Page through the file using Star Office
  3. Do a cat of the file in the Terminal
I ran the tests on 3 Sun Ray servers on our lab network:
  1. Linux
  2. Solaris Sparc
  3. Solaris x86
I monitored the network traffic from a Linux box on the same hub as the Sun Ray client, using the "tcpdump" utility. Instead of merely counting the number of packets in and out of the Sun Ray client, I counted the total number of bytes as well as the total length of time for each test. To achieve this, I wrote a small Python script to process the ASCII output of a tcpdump session and print a table displaying the time and total number of bytes transferred for each test.

To ensure repeatability and detect any variations I ran each test 3 times.

Before each test I logged in to a new session so that any memory leaks or other potential performance problems from an older login may be avoided.

I also ensured that the screen remains static before each test, eg: by having the GNOME clock applet not display seconds, and by having the terminal not use a flashing cursor. This way I could ensure that network traffic before and after each test consists of a constant (roughly every second) flow of small (40 byte) keep-alive packets.

To minimise variations in human interaction, I attempted to make the tests require as little human intervention as possible, and to make each test fairly long so as to make those variations negligible. Eg: The terminal test does a "cat" of a large file instead of requiring the user to perform a set of command-line operations. Some tests do require human intervention, Eg: the browser test requires the user to constantly press the PAGE-DOWN key to keep the page scrolling.

I ran the tests on CDE and JDS on the Solaris Sun Ray servers, and JDS on the Linux Sun Ray server (since Linux does not have CDE). Then I set the GNOME system fonts on JDS to Monochrome and repeated the tests. This speeded up the terminal and browser, however it doesn't speed up Star Office, which renders its own fonts. On Solaris, StarOffice is very fast so I didn't change fonts. However, on Linux I changed the Star Office fonts to use non-scalable fonts, ie. from "Thorndale" and "Albany" to "Fixed" under Tools->Options.

The following result table was generated by processing the dump files with a python script. To reduce the space of the table, I have only included results for Linux and Solaris x86 (Solaris sparc had similar results to Solaris x86). The green lines indicate the total time taken for each test, and the brown lines indicate the total number of bytes transferred between the Sun Ray client and server during that time.

The CDE results vary significantly from a very slow Browser to a very fast Terminal.

On JDS, both the Browser and Terminal are slow. But when set to use Monochrome fonts the performance of all three tests are pretty similar - on both Linux and Solaris.

So, the question for JDS is whether the monochrome results are acceptable in terms of performance, and then also whether they are acceptable in terms user experience: we can't have people using monochrome fonts that render faster but look bad. Our usability engineers should see if there are monochrome fonts that are of an acceptable quality to ensure that users are able to enjoy using JDS on a Sun Ray.


<<<The results show that CDE's Terminal can "cat" a file blindingly fast compared to JDS's "gnome-terminal".>>> [Sigh] Read this please... the thing to remember about terminal performance is that you can trade off update rate with throughput to your heart's content. That is, to make a really fast terminal, never update the screen until the child process stops outputting. To make a really slow terminal, update the screen every time the child process outputs a single byte. To make a reasonable terminal, pick some spot in the middle, or try to come up with a fancy algorithm for when to repaint. To compare the paint speed or parsing speed of two terminals you probably have to somehow get those two terminals to follow the same rules on updating, and you may also want to configure them feature-equivalent in terms of font rendering and i18n. Moral of the story is that when optimizing a terminal you can't just make it as fast as possible, you first have to define the behavior/features you consider acceptable, and then stay "within spec" as you optimize. Anyone can write a fast terminal if "cheating" is allowed but it isn't clear what constitutes "cheating."

Posted by Phil Wiggins on June 08, 2005 at 05:03 PM IST #


GNOME Terminal is extremely slow on systems with poor RENDER extension performance. This is the same on Linux or anywhere else you go. If your X server has no RENDER extension or its implementation is slow (alas, most are - grr), GNOME Terminal will be painful.

With fast RENDER support, it's quite snappy and nice, and you get to keep your nice fonts. It works fantastically on my NVidia-based Linux desktop (hw accelerated RENDER), for example. Unfortunately, most RENDER implementations are apallingly slow, including the stock X server one. IIRC it was always meant to be improved and optimized later, but that never happened. Few drivers accelerate it either, partly because last time I checked there was no documentation on how to implement RENDER acceleration. This, of course, means lots of "fun" for users.

If I had to make a guess, I'd say the SunRay's built-in X server probably doesn't have the RENDER extension, so the client is instead using the raw X11 protocol to draw the glyphs. Unsurprisingly this is slow. Try setting the GTK_USE_XFT environment variable to 0 in the user's login script - BEFORE any GNOME stuff starts - and see if that makes a difference. I'm not actually sure that's still supported in the recent gtk releases, though.

I'm not familiar with the SunRay (I'd like to be, though \*grin\*) so the bit about RENDER is just a guess, but it matches what I'd expect from your description.

Posted by Craig Ringer on June 08, 2005 at 08:32 PM IST #

Actually, it looks like the right env vars may be:


... they certainly do an impressive job of uglifying Firefox here.

P.S: Your

style could use some more spacing between paragraphs (a half line maybe) ... it's really hard to read currently, especially in comments with long lines and/or short paragraphs.

Posted by Craig Ringer on June 08, 2005 at 08:46 PM IST #

Can you verify that you are using the same browser version in all of the tests? Your difference in browser results could be due to difference between Mozilla 1.4 and 1.7, for example. As for terminal performance, the CDE shelltool doesn't skip any rendering. It's pretty obvious when you cat a large file that it's all getting painted. We have a font cache on the Sun Ray itself for X fonts, so rendering non-AA X fonts on the Sun Ray is very fast. And yes, your guess about RENDER is correct. We don't implement it. Also, there is no built-in X server on the Sun Ray. The X server runs on the server and there is a remote frame buffer protocol between the server and the Sun Ray. (Similar to VNC, but with better performance because we don't just do frame buffer scraping, but pass many graphics operations through to the Sun Ray.)

Posted by Kent Peacock on June 08, 2005 at 09:27 PM IST #

Kent, given that the X11 protocol handling - is done server-side, not on the thin client its self, that would seem to make my evaluation of the situation quite a bit less likely, since the performance of RENDER or client-side fallback font rendering shouldn't enter into the equation. That makes these results all the more interesting.

From here on in is guesswork. I don't even have CDE to test with right now (Solaris 10 was displaced from my desktop - might make it back when I can get the source, some newer libraries, and a more up-to-date toolchain easily.). Still, maybe it's useful guesswork and speculation.

I assume the font cache is used only for X core fonts? My understanding is that the font caching you describe can't work for xft2 apps, since they do font rendering client-side even if there's no RENDER support; it's just less efficient w/o RENDER. I expect the CDE terminal uses X core fonts (server-side fonts), and gnome-terminal will always do font rendering client-side - with or without RENDER. That probably means that the SunRay doesn't get to benefit from its font caching with gnome-terminal, but it can with the CDE terminal. This might explain the performance difference observed, and a similar explanation might apply if the browser and StarOffice binaries are built w/o xft support in CDE, but with it in JDS.

The significant performance improvement with monochrome fonts under JDS should make sense if my guesswork above is right. If I understand the situation correctly, gnome-terminal is still not using server-side fonts, but the rendering operations are \*way\* simpler because of the bitmap fonts.That should mean they use less bandwidth and are faster, explaining the results above.

Sound like there might be some sense in this wild speculation?

Posted by Craig Ringer on June 09, 2005 at 07:41 AM IST #

> Sound like there might be some sense in this wild speculation? <PP> Yes, you've got it pretty close to correct. We don't support RENDER in either the X server or the Sun Ray itself, so the xft2 fonts are very expensive. The monochrome fonts are much faster and take much less bandwidth mainly because they comress to bitmaps, whereas the AA characters are essentially images, with arbitrary pixel values on the edges. Unfortunately, the monochrome fonts are way uglier than the X core fonts, otherwise using them could be an acceptable compromise. <PP> It's going to be a difficult problem to solve.

Posted by Kent Peacock on June 09, 2005 at 09:34 AM IST #

How about benchmarking a recent xterm too? Gnome terminal in my experience tends to be slow, and sometimes messes up the display (not talking about not supporting 256 colors output...)

Posted by anon on June 09, 2005 at 10:33 AM IST #

Craig and Kent, thanks for your input so far.

A few comments/answers:

<code>> P.S: Your style could use some more spacing between paragraphs</code>
Yep, this is my first blog entry, posted soon after I spent only a few hours setting up my blog - so it will improve over time, thanks.

<code>> Can you verify that you are using the same browser version in all of the tests?</code>
Kent, yes - it's Mozilla 1.7 on all of them.

Thanks for your info on Sun Ray font caching and AA versus Monochrome tradeoffs. Am I right then if I say that Sun Rays can display (deliberately avoiding the term 'render' here since the actual rendering occurs on the server) fonts in 3 ways:

  1. X core fonts - look fairly good, cached on Sun Ray client for performance.
  2. Xft2 fonts - look very good, but are (expensively) rendered on the server and result in large amount of data sent to Sun Ray client.
  3. Monochrome fonts - look fairly ugly, but result in small amount of data sent to Sun Ray client.
The trade-off then seems to be between AA fonts that look good but perform poorly, and Monochrome fonts that are fast but don't look so good.

Or, if GNOME could be set to use X core fonts that can be cached on the Sun Ray... would that be feasible?

Else, it might boil down to using Monochrome fonts, but selecting ones that look the best - there is probably great variability in the quality of Monochrome fonts.

Finally, I have heard that Sun Rays can automatically perform optimizations when used over a slower network connection, eg: broadband at home versus LAN at work. I would like to find out more about it, and perhaps conduct the tests using a Sun Ray over broadband...

<code>>How about benchmarking a recent xterm too?</code>
I'll consider doing that next time - would be interesting.

Posted by Johan Steyn on June 09, 2005 at 11:05 AM IST #

See also bug #122656. Good luck getting it fixed.

Posted by Rich Burridge on June 09, 2005 at 04:15 PM IST #

I don't think GNOME can really use the X core fonts for anything. My guess is that almost all of the monochrome fonts will look bad, since they're totally untuned.

Yes, the Sun Ray uses adaptive compression over low-bandwidth links. There are about 1500 Sun Rays deployed "at home" using Cisco VPN routers in a pilot.

xterm should behave about the same as shelltool in CDE, since it uses the X core fonts. That's how I solve the gnome-terminal problem when I use JDS - I set my default terminal to xterm.

Posted by Kent Peacock on June 09, 2005 at 06:40 PM IST #

I also tend to just use `xterm' under GNOME, being careful to select a bitmap font. Handily, xterm is also much better at emulating unusual terminal features and modes, which I need.

The terminal performance problem will need to be solved sometime - both for the general GNOME desktop case (where slow RENDER in the X server is the problem) and for the SunRay by the sounds of things. Hopefully improving the X server's RENDER implementation should sort it out for normal use, but that won't help the SunRay or any similar thin client.

You might want to look into how NX from handles this - gnome-terminal over NX on a 1.5MBit ADSL link performs better than it does locally on some machines. The source is available from their website, but IIRC it's GPL so it's probably only useful to you folks for reference.

Posted by Craig Ringer on June 09, 2005 at 11:49 PM IST #

In addition to graphics performance, you want to look at the overall system performance effect of your choices.

The problems I've seen with GNOME are related to the large number of resource-intensive processes it starts, such that when you have multiple users on a single Sun Ray server, the whole system tends to bog down.

Right now we're using fvwm, but it would be nice if we could afford to move to JDS when we move to Solaris 10. However, this will require solving this problem, if indeed it can be 'solved.'

Posted by Jim Gottlieb on June 12, 2005 at 05:29 PM IST #

How does one set the local font cache?

Posted by Jesse Carroll on January 29, 2007 at 08:25 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016