If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

How Unity, Compiz, GNOME Shell & KWin Affect Performance

05-30-2011, 02:00 AM

Phoronix: How Unity, Compiz, GNOME Shell & KWin Affect Performance

Those that follow my Twitter feed know that over the weekend I began running some benchmarks of the various open-source and closed-source graphics drivers. But it was not like the usual Phoronix benchmarks simply comparing the driver performance. Instead it was to see how each driver performed under the various desktops / window managers now being used by modern Linux installations. In this article are the first results of this testing of Unity with Compiz, the classic GNOME desktop with Metacity, the classic GNOME desktop with Compiz, the GNOME Shell with Mutter, and the KDE desktop with KWin. These configurations were tested with both the open and closed-source NVIDIA and ATI/AMD Linux drivers.

Nice benchmark, and interesting numbers.
I am using KDE 4.6.3, with a GTX 460 and although I use compositing most of the time I have to turn it off even when playing games like gnujump in windowed mode since it causes horrible performance.
The problem is of course even worse in more demanding 3D games.

I take it the performance in your benchmark is due to using the (by default in most distros) "undirect windows" option and fullscreen benchmarks, which isn't much different from benchmarking the desktop without compositing.
It would be interesting to see compositing benchmarks in KDE without using this option, or running the benchmarks in windowed mode, and then comparing it to suspended compositing (Alt+Shift+F12).

Comment

Nice. Any chance you can run a similar benchmark looking at idle CPU usage and power usage? I remember Martin Gr??lin saying a little while back that kwin's power usage with desktop effects on shouldn't be any higher than with them off, but that's not been my experience (nvidia driver). Anyway, would be interesting to see how all these compare on power management.

Comment

You didn't mention, in the test, the use of the Compiz or KWin options that disable compositing for fullscreen apps, thus games !

* By default, KWin turns off compositing for fullscreen apps and should be as fast as Metacity (don't know why it turns out to be faster ?!). This option is great but makes the screen flicker a little when switching from windowed to fullscreen mode. In the future, there will be an API, apparently, so that apps can tell if they are more demanding or not, and if compositing should be switched off or not. (way to go, IMHO !)

* By default, Compiz doesn't and you have to install "ccsm" and tick "undedirect fullscreen apps" and you want to play games with the most FPS.

I'm pretty sure KWin would not be faster than Compiz, if that was taken into account. (well, there will be MUCH performance improvement in KDE 4.7, too)

Comment

I'm shocked that KDE is doing the best. I'd like to see a *box window manager up there...

KDE? There's no reason it shouldn't perform well in benchmarks like this as far as I know, as long as the system doesn't run out of RAM or run into a bug of some kind. This is more a measure of how much the different desktop shells/compositors can keep out of the way when not in use than a measure of how fast the compositor can paint windows or the desktop applications can run, hence why quite a few of the results are quite similar.

The few instances where KDE with the nvidia driver is significantly faster than other shells is a bit anomalous though ? then again all the other shells are based on the gnome desktop.

Comment

To be fair, testing out 3.0-rc1 is like taking a random VCS snapshot of the Catalyst driver about a week into the development of a new release stream (before even a beta is available). The release quality of a rc1 of Linux is equivalent to a pre-alpha of any other software. Reporting the issues you have is a good thing, but the quantitative results (or the absence thereof, due to breakage) are less meaningful until we get a few rounds of bug-fixing.

IMHO you should have reverted to the stable 2.6.39 series for the open-source driver testing, as soon as you realized that there was serious breakage with 3.0-rc1. My experiences with r600g on 2.6.39 aren't nearly as broken as you describe; at the very least, compiz, unity, mutter and metacity all work without rendering issues or significant performance problems.