Recently I did some refactoring around the Compositor and there was one change where Thomas was afraid that this would cause a performance regression. So I used Valgrind’s callgrind tool to verify if this is true. And yes the code had a slight performance drop, though it is luckily not in the hot code path and even if the overhead would be rather small.
But having the callgrind log I looked a little bit closer into it, which I haven’t done since the last optimization for I think 4.8. Since that is quite some time ago and I had basically forgotten how it looked like back then, I was shocked about a few results. So I knew that in the last optimization I adjusted all effects to be not active by default except the translucency (and blur) effect.
Now looking at the results I saw that the translucency effect is rather expensive and that by default the effect is not doing anything unless you are moving windows. This is of course a rather unpleasant behavior to have an expensive effect doing nothing. So I looked at the implementation and found a way to better track when the effect should be active. Unless you have enabled the effect to set decorations or inactive windows to translucent the effect is now disabled by default. Just when you start moving a window the effect gets active. And even then the effect performs better.
But there was more into it. So I noticed that there is supposed to be an animation when a window starts to move, but personally I have never seen it. Looking closer at the code I noticed that this could have never worked. I decided that an animation added to 4.1 which has never worked can be dropped which again improves a little bit the performance. We might add a better translucency effect for 4.10 which adds the animation again, but for 4.9.x there is no user visible change by removing the animation.
But still I could not fully understand why the effect is so expensive, all it does is checking the type of the window multiple times: is it a desktop? is it a dialog? and so on. That cannot be that expensive, but it is. I tracked down the expensive call in KCacheGrind and found that the check for the windowType() is expensive.
The code had quite some surprises. It gets the window type, calls the window rules to have user specific overwrites and some hacks to fix some special windows. One of the hacks was to make menus with a certain size being a top menu. This hack must have been for the time when the top menu had not yet been implemented as a kicker applet. Not only is it unlikely that anybody is using such a combination of KWin and old KDE versions also KWin has not supported the top menu at all in any 4.x release and the code got dropped a few releases ago. Which allowed us to savely remove that part.
The second hack is even more intersting. It is a workaround for a dialog in OpenOffice.org 1.x added in 2003. For this hack each time the method was called a complete string comparison had to be done in case the window is a dialog. Again the hack was quite outdated given that on a modern system you don’t have any windows with the name openoffice, but only libreoffice. Also I searched through the LibreOffice help to find the dialog in question and verified the window type: the hack is no longer required. Both hacks are removed for 4.9.2. The lesson to be learnt from that: never add hacks to your application, they stay. In general I would not accept workarounds for applications inside KWin anymore. This clearly belongs to the area of window specific rules and scripts.
But the main optimization of this method will be available in 4.10. The output of callgrind showed that this method was causing quite some expensive dynamic casts. In fact each call caused two dynamic casts to check whether it is a specific sub class and basically the method contained two interwoven implementations for the two specific sub classes. The logical step was to make the method pure virtual and implement it in the sub classes. According to the callgrind logs after the change this improves the performance quite a lot (I cannot say whether this can be noticed by a user, for this it might be too small, but it should be noticable on the battery). Given that this is not just dropping of hacks but a refactoring it cannot go into 4.9.2 as there is still the risk of a regression.
Interestingly when the method got implemented the approach was correct and also not expensive. From within the window manager code path it gets only called very few times, in my dataset it’s about 10 % of the calls coming from the window manager and it seems like most often to be called when a window gets added, so on a longer running session the amount would be even smaller. The code got expensive when it became to be used from within the effects system which is compared to the window manager a rather hot code path. Which is also something important to remember when optimizing: check whether the expected methods are in the hot path. This is now the case for KWin: the most expensive call is the one to render a window, the second most expensive the one which starts the rendering of a frame. And for those I’m already working on further optimizations for 4.10.
Thanks very much for your ongoing effort! Those posts are also great! Please keep them coming 🙂
Very good work, love reading your blog posts…
When I read about this kind of things I can’t wait for the next release to test them out.
Actually, there is always something great in the next KDE release that makes you wait impatiently for the next version.
When KDE 4.8 was coming I had to compile myself Dolphin 2, couldn’t wait a few months for it…
+ 1
even if i’m not a developer i enjoy reading these posts. Thanks for all your efforts!
That’s some good engineering you did! Super.
Sweet! Looking forward to trying these things out. 🙂
Great news! Good job Martin & kwin devs. Performance improvements news are like honey to my ears. Keep rocking! Make kwin uber window manager!
Nice 🙂 I’m still waiting for kwin to not show up in `top` on an idle system; it’s not there yet when compositing is on, but it’s getting closer with every release 🙂
you can never have KWin not show up on top. Someone has to bring the numbers of top to that screen, that someone is KWin.
Yes, but should it really, on a completely static screen (no animation, `top` running in a deteched `screen` terminal) and on modern-ish hardware (core2 duo@2.5GHz, intel graphic card using i915 driver) take an average of 2% of the cpu ? Be the second biggest aggregate cpu user after X but before virtuoso, plasma, emacs, konsole, and krunner (ignoring programs that aren’t running for the whole session) ? If running with compositing disabled, kwin stays at the bottom of the list, rather than the top.
then something is happening. on a completely idle system KWin is not doing anything. You can use the show paint effect to see whether something is going wrong. WARNING: do not use show paint effect in case you suffer from epilepsy
here, on another i915 sys, kwin is usually to be found using well below <1% but periodically spikes up to 2% when doing nothing.
I read so many blog posts and comments about KDE or free software in general that developers are only interested in new features and do neither fix bugs nor track performance bottlenecks. KDE and especially you are a great counter-example. Thanks for your afford and I am again looking forward to the next, even more polished KDE SC release.
there are a quite simple reasons for that wrong perspective. First of all blogging about performance improvements or fixed bugs is not something everybody likes. It means admitting that there have been bugs or that the application is slow. When I did the major performance improvment last year I got many comments in the area of “your so stupid, why didn’t you run valgrind earlier” – that makes one wonder whether it’s worth to blog about performance improvments.
And it’s much easier to blog about awesome new stuff, showing a screenshot or a video than blogging about boring internal details.
An example for what I explained. You cannot write about bugs without others thinking they are smarter.
Last time I’ve tried kde 4.9, kwin showed tearing in the upper portion of the screen, using nvidia proprietary, just like mutter or compiz.
Mutter and compiz fixed that, and I would like to see that fixed in Kwin, because it’s a very good compositor, and the only one that shutsdown effects completely while running fullscreen apps.
And, by the way, nice photo of that portuguese tram :), I see you visited my nice country.
No, it’s a default wordpress background. I’ve never been to Portugal so far.
Unfortunately the “fix” means to use fullscreen repaints, so this should be fixed by nvidia (they seem to sync to the end of the vertical retrace instead of the beginning when using glXWaitVideoSync)
That said: kwin doesn’t actually enter the buffer swapping path whenever it actually could (because it repaints the entire screen but the compositor is not aware of that in the relevant location)
That’s sth. that could get fixed and by that avoid that tearing for fullscreen (or maximized) applications.
You guys are amazing! I don’t know if it’s nvidia or kwin (I think both) but since 4.9 there is no more tearing on upper part of the screen for me, moving windows around is pure joy 🙂 I call, best release ever! (yeah, no surprise, every new release is better then earlier one 😉 But this is on decent PC. Still waiting for more improvements! Kwin lately has gained a lot of good PR, don’t waste it 🙂
thanks for your job.
is libkwinnvidiahack still needed with >=4.8.4 ?
it’s still used, so I think yes.
You rock!
I always enjoy reading about performance improvements, and I think many people does aswell. The critics represent maybe 1% of the readers.
For me, KDE 4.x is feature complete. But it always can be improved with more performance & bug fixes.
Another thing you can do to improve KDE is to look at responsiveness (real and perceived), although that can get tricky to measure (I have no idea).
Keep your hard work.
Call me stupid, but I don’t like tabs in my browser. Instead, I open each page in a separate window. Right now, I have 41 Konqueror windows open, not counting some Konsole windows and other stuff.
I remember that one year ago, KWin got unusably slow with that many windows. Opening a new window needed ages, even simply scrolling in the front-most window was slow.
Today, I don’t even notice a difference between an empty desktop, and desktop with lots of open windows, and I am amazed that you still find ways to improve performance.
Keep rocking!
awesome work! Martin
Your bugfixing/cleanup job is great and makes KDE even better, thank you.
Performance improvements are currently the best news for me when it comes to KDE, especially KWin, Akonadi and Nepomuk. All the features are just awesome and I currently don’t miss anything so performance improvements absolutely rock.
How evil to announce such improvements right after release and one month from the next. 🙂 But then I remember that in Gentoo it’s just a matter of cherry-copying your patches into /etc/portage/patches/ and there I am, already enjoying your latest work. 😀
sorry, my development model is pretty much decoupled from release schedule
Nothing’s wrong with that. 😉 I just wish sometimes kde had a less stiff release schedule. For a long time I was simply pulling from stable-dev trunk because of that so I could get improvements and fixes for specific packages earlier.
I want to let you know, that I was a KDE user in the 3.x days, but after KDE4 came out, I switched to gnome with tiling WMs like awesome and Xmonad. I was happy and more productive with these WMs, and that they are very customizable, especially Xmonad.
I tried every major release of KDE4, but I always felt that something missing, that it could be a good thing but still slow, buggy, and I have to touch my rat too many times. Because of the slowness and bugs I purged KDE again and again after every install. Now I tried 4.9 and I am really amazed. It’s fast, slick, good looking, and I already started customizing it to my needs.
Awesome job, keep it up 🙂
Sweet. You rock man.
Thank you.
Thank you guys!
Great, can’t wait to put it on my Gentoo