You tell us in the text that the y-axis shows time in milliseconds (except for the first graph, where it apparently shows time in some other scale), but you never tell us what the numbers on the x-axis represent, so we are left to *guess* what they might mean from your analysis of the graphs.

If the KDE community wants to gain serious traction among people other than developers and hardcore KDE fans, they must begin focusing on stability and reliability, and then performance, while relegating experimental features and refactoring and rewrites into branches that are THOROUGHLY tested and vetted among a wide userbase before being released as part of the SC.  If this means that some code doesn’t get released for a long time because there aren’t a lot of testers, so be it–better to delay a new feature for a long time and get it right than force it upon users who have to suffer as unwitting beta testers. 

The alternative is for KDE to remain a developers’ playground for the foreseeable future, in a constant state of flux, doing cool things over and over again, never quite reaching maturity, never at a point where people can rely on it for serious use.  

Maybe some KDE folks are content with that. But KDE could be so much more. KDE needs stronger leadership and direction. There is so much wasted effort right now, people reinventing and rewriting code while important components are neglected, people working on long-shot experiments that will never be actually used, even writing code for devices which don’t exist on the market. In the meantime the existing desktop market gets neglected–just simple network management in KDE is a mess compared to Unity or OS X. There’s one guy working on it, and he just took it over–but there are plenty of experienced programmers in KDE who could have fixed it up years ago. 

You know, I can’t stand GNOME 3, either the software itself or the way they’ve gone about the process and snubbing the existing community–but I will give them this: somehow they have worked together to achieve their vision, whether it’s a good vision or not. I don’t want KDE to blindly follow one person’s vision, but it needs to strike a middle ground–this free-for-all that’s been going on the past few years is not accomplishing much. Yes, I know the underlying foundations and libs are way way better than KDE 3, and the magic moment when it all comes together is just around the corner–except it’s not, because people keep reinventing the wheel instead of building the rest of the vehicle. Better to have a car with less than perfect wheels than to have perfect wheels rolling around aimlessly.  The fact is that KDE 4 as a DE is not that much better of an experience for a user than KDE 3 was. Sure it’s shinier, but as far as actually using it, it’s about the same. 

All of KDE is made by volunteers who are free to do whatever they want. But if they would put off rolling their own little snowballs and work together rolling one big one for a while, KDE could start quite an avalanche. Please put aside your experiments for a while and fix the bugs and optimize performance and make what KDE is now really shine. 

which image, sorry? There’s none in this post

My $0.02 in summary…

…is that you really shouldn’t worry about things like this unless profiling shows it is a real problem on real world code. Microbenchmarks, like this one, are great for examining things that you’re curious in, but you shouldn’t let this have an impact on how you write code by itself, really.