After a few threads about debug builds and release builds on kde-core-devel I figured I was wrong in my previous entry, KDE 4 couldn't easily be build without debugging symbols. So my build WAS a debug build. But now it's possible to have it clean and fast, and I did indeed see an increase in performance when trying it.
Apps start up even faster, it's rather weird to see an application which always took a noticeable delay to start up now pop up like its a basic calculator ;-)
Drawing is also a bit faster, but still clearly not as fast as in KDE 3. Resizing dolphin on KDE 3 is almost entirely smooth - very unlike the rather unpleasant experience on KDE 4. Gwenview is a bit faster, it doesn't draw an image visibly when you drag it anymore but clearly isn't as smooth as the KDE 3 version. It IS faster loading large images though, a 6400x3200 image loaded in a snap (!) while the KDE 3 gwenview made me think it got stuck...
And here's a new Konqi-auto-scrolling picture. It starts with XPLANET (nice 20, yes), then 5 seconds pause, and I start scrolling the Konqi from KDE 3. You don't see a visible difference in CPU usage... When I increase the speed of the scrolling, there are some very small spikes but generally the CPU is still barely used.
The picture for KDE 4 is different - approximately 10% of my cpu is needed to scroll a page slowly, which increases to 20% when I increase the speed of scrolling.
Notice that these numbers DO represent a decrease compared to my previous test, which showed twice as high CPU usages in KDE 4. So it might be no more debugging, or some performance work - either way, Konqi got twice as fast already ;-)
As discussed on the other blog post, this is all with a dualcore 2.4 ghz AMD, 3 gb ram, proprietary NVidia drivers (geforce 6600) and NO compositing. Tests are run in a KDE 3 environment. Yes, double-buffering is on in Qt4 - as it should be, it looks horrible without... The whole area flashes when scrolling.
One person mentioned a potential scrolling bug in Qt4, which makes it redraw the whole area when scrolling. This could indeed explain the flickering without double-buffering and the performance problems, I guess. Hopefully a new Qt version fixes this, I found quite a few scroll-speed related bugs in the TT bugtracker.
I think I can conclude the performance issues with drawing are not as bad as I depicted in my previous blog, and it's very well possible they can and will be fixed. Meanwhile, KDE 4 performs amazingly well in many other areas - most noticeably application startup.
EDIT: With some help (see comments) I was able to compile QtCurve for KDE 4, and tried it. Some argued the slow drawing when resizing might be due to Oxygen behing slow, and that showed indeed at least half true. Dolphin resizes faster with Qtcurve - but the KDE 3 version is still much more smooth.
So, how do you completely turn off debug with kde4 from svn?
ReplyDeleteTry installing QtCurve kde4 theme if you want redrawing to be fast. For me, with oxygen style redrawing is slower than a snail stuck in treacle, but with QtCurve it's as fast as kde3. YMMV
ReplyDelete> Apps start up even faster, it's rather weird to see an application
ReplyDelete> which always took a noticeable delay to start up now pop up
> like its a basic calculator ;-)
yeahh!! finally! :)
that's what I always hoped for, because it's just weird to have applications start up that slow at modern systems. KDE 3 always felt slow because of this.
Thank you for your interesting blogpost. It is nice to read an unbiased, empiric view on the performance of KDE4.
ReplyDeleteUsers always say "this is faster than that", but they seldom have numbers to prove it.
I am still hoping that one day, KDE N will be faster than KDE N-1 and the software bloat will lose. I am certain that performance measurements are the key to victory. Rock on!
It seems related to QScrollBar.
ReplyDeleteProfiling konqueror in auto-scroll mode, I obtain 50% (!!) of the time spent just repainting the scrollbar.
Switching to a simpler style doesn't seem to help much.
@1st anonymous: you can now turn it of by just compiling with cmake in release mode:
ReplyDelete-DCMAKE_BUILD_TYPE=release
should do the trick.
@Martin: KDE N is mostly faster than N-1, didn't you notice that over the last few years?
@last anonymous: that sounds rather bad... I checked the TT issue tracker and I can't find anything which sounds related - maybe you should file a bug there?
Oh, and, to not ignore you two:
ReplyDeleteBenji w: I can't install QtCurve, it doesn't compile.
@diederik: I can only agree ;-)
It's a trivial patch to fix QtCurve compile, here's the one from suse package http://bw.uwcs.co.uk/qtcurve-FIXME.diff
ReplyDeleteYou could try Quarticurve. ;-) Not as configurable as QtCurve (it's a straight port of the original Bluecurve code, whereas QtCurve has been forked from it ages ago and seen lots of changes), but at least it compiles. ;-) I don't know if it's faster or slower though, the only thing I really cared about is matching the Bluecurve look as much as possible.
ReplyDelete