kdevelop Syndicate content

warning: Creating default object from empty value in /www/htdocs/w0065fc9/milianw/modules/taxonomy/taxonomy.pages.inc on line 33.

» Kate/KDevelop Sprint Vienna 2012 Take 1

Thu, 10/25/2012 - 13:37

Hello everyone!

Finally I take some time to blog again. I’m currently in Vienna for the joint KDevelop/Kate sprint together with lots of other hackers. Many thanks to Joseph for planning and partially financing this sprint! And of course as usual many thanks to the KDE e.V. and all the donors for bringing in the rest of the money required to pull something like this off!

Anyhow, considering that the sprint is running since Tuesday, I need to catch up quite a bit… Actually, I have to start even before that since I committed something quite noteworthy in KDevelop and KMail last week.

Reducing Memory Consumption
Shared Data References

I attended the recent Akonadi sprint that took place at the KDAB office in Berlin (where I work btw.). I heard that Alex Fiestas would come and show us his memory problems in KMail, which sooner or later was eating multiple GBs of memory for him. That sounded like a fun task to improve, fixing performance issues is what I love to do :) So I investigated it with Valgrind/Massif and my pmap script. After quite some time I came up with a patch to fix the memory increase, which is waiting for Stephen Kelly to review. It should be merged into master very soon™.

Now some technical background: What was the issue here? Why wasn’t it found earlier? Usually developers run e.g. KMail through Valgrind with the leak checker and fix all issues. The same was done lots of times in KMail, there where no problems reported. Why then is the memory still increasing over time? The issue is, that this is technically not a “leak”, i.e. when you close the application all memory is properly released. Instead, there was a logical error that resulted in KMail’s ETM (basically the item model for mails and stuff) push shared data items into a QHash without ever deleting them. If you close the app though, the QHash is cleared automatically and all shared data is properly freed, hence Valgrind won’t report any leaks.

How does one find such an issue then, though? Actually, this is really hard… I ran KMail through Valgrind and looked at the top allocation, which relates to the shared data item. But Massif will only show you where the data is being allocated, not where the shared data items are still referenced and thus prevent a proper deallocation. What now? GDB! Yes, the best way I found was adding a breakpoint in the copy constructor of the shared data class and looking at the surrounding code to see whether it behaves properly… Does anyone have a more efficient way to debug such issues? I could imagine that this can potentially take ages to figure out… In KMail at least I could find the problematic place quite fast.

Implicit Sharing

Now while this apparently fixes the ever increasing memory consumption of KMail somewhat, I thought we could do some more improvements. Take a look at https://git.reviewboard.kde.org/r/106836/ e.g. This patch is similar to what I also did for Massif Visualizer once. By creating a central cache we can leverage Qt’s implicit sharing for common strings (in this case email e.g. adresses, domains, …). This way, if you load a folder containing e.g. a mailing list, you will have the main email address (like list@domain.org) only once in memory. Before, that address would be loaded into memory once for every email in the folder…

Now the above was an interesting detour into a project that I don’t usually contribute to. Since I use KMail all the time though, it is just fair to give back and help out the few KDEPIM people a bit.


Back to my favorite pet project: KDevelop :) In the spirit of the memory fixes above, I took another look at the memory consumption of KDevelop. Turns out, we had a similar issue where we did not reuse implicit sharing properly. This resulted in quite some useless allocations blowing up the memory consumption (in this case, KUrl’s of every file in the projects loaded for a session). The fix is already in master. Not only should that decrease the memory consumption considerably for kdevelop sessions with many files in it. No, it actually should save quite a few instructions and thus be much faster as well. Enjoy!

So… quite a long blog post again - sorry for that :) Expect some more KDevelop news the next days - we have lots of interesting stuff happening here at the sprint! Cheers and many thanks to Joseph and the KDE e.V. again!

» KDevelop 4.4.0 Welcomes You!

Tue, 10/23/2012 - 17:32

Hey everyone!

A first broadcast from the joint KDevelop/Kate sprint! Many thanks already to Joseph for planning this all. As you can see, we also have net access and thus nothing can prevent a very productive week :)

Anyhow, back to the actual news: I finally announced the release of KDevelop 4.4.0. Many thanks to all involved again.

Mind you though, the change list is a bit sparse this time. Yet I’m really looking forward to the 4.5 release already. I’ll blog about it in the next days during the sprint. Stay tuned!

» KDevelop 4.4.0 Beta 1 Released

Tue, 08/14/2012 - 18:01

Hey all!

After quite some slacking on my side, I’ve finally managed to drop the good news: KDevelop 4.4.0 Beta 1 is released!

Our 4.4 branch already contains some more interesting changes for the next beta, stay tuned. Oh and yeah, we’ll try to release 4.4.0 final sometime in September, I hope.


» KDevelop 4.3.1 Released with improved GCC 4.7 compliance

Thu, 04/19/2012 - 10:58

Hey all!

KDevelop 4.3.1 is out! Go read the announcement and update.

Many thanks to all contributors, you rock :)

» KDevelop 4.3.0 - Go Get It!

Tue, 03/20/2012 - 13:21

Finally I managed to get my job as the release dude done: http://kdevelop.org/kdevelop/kdevelop-430-final-released-basic-c11-support

Thanks to all the developers who sent in patches! The same goes to our loyal users for their continued support and bug reports :)

It’s really fun to work on KDevelop and - I’ve said it many times before - I’m really looking forward to our next releases! Even now our code in the master branches has some neat commits that make the eventual 4.4 release something to look forward to!

» KDevelop Forum & Screenshots

Mon, 02/27/2012 - 17:44

Hey all,

following the recent blog post on getting a forum for KDE software I decided to get one setup for KDevelop. Minutes after, it was all done, we now have a KDevelop Forum. Feel free to use it for discussions and user support around KDevelop and related applications. Development discussions etc. will still happen on our mailing list though.

To get the forum rolling, I’ve had the idea to use it for some crowdsourcing of KDevelop screenshots, see also the post on the KDevelop website: http://kdevelop.org/community/new-forum-screenshots .

» KDevelop 4.3.0 RC 1 Released

Sat, 02/25/2012 - 18:45

Hey all!

Please help us test KDevelop 4.3 RC1! Grab it while it’s hot: http://kdevelop.org/43/kdevelop-430-rc-1-released

This release comes with some more bug fixes and better support for some C++11 language features.


» KDevelop 4.3.0 Beta 2 Released

Tue, 02/14/2012 - 15:10

Hey all!

I’ve just posted the news on the KDevelop website: KDevelop 4.3.0 Beta 2 is released!

Please test it and report feedback as usual. I think it’s safe to assume that we will release 4.3.0 final in about 2-4 weeks from now.

Considering that my university semester is nearing its end, I will finally have more royal hacking time again! I’ll continue to squash bugs and improve the performance of KDevelop of course :) Most definitely I’ll try to further improve the C++11 support. But maybe I finally have some time again to work on “something bigger”, like helping Miha Čančula in writing a kick-ass unit-test integration for KDevelop (see unittest branches). Then I plan to finally release some more of our “playground” plugins, most notably CSS language support and QMake project management…

Stay tuned for a bright KDevelop future :]

PS: I’ll step up as a mentor for a KDevelop GSOC this year, yet I’m still wondering about a proper topic… Ideas?

» VTune and KDE

Fri, 09/09/2011 - 21:09

Hey all,

been some time since I blogged last time. My TODO list is ever increasing and I took my day job at KDAB up again. Among others, I attended a marketing talk by Edmund Preiss. He actually made that marketing talk interesting, not least by his huge knowledge in the business, thanks to ~20 years of working for Intel. Probably the most important info I got out of it is this:

VTune is available free-of-charge under a non-commercial license

Yes, you heard right. Take these links:

  • Intel’s non-commercial offering

    note this entry from the FAQ:

    What does noncommercial mean?
    Non-commercial means that you are not getting compensated in any form for the products and/or services you develop using these Intel® Software Products.

  • Register for free license

  • Register for Download Access

    you’ll need the serial number that gets send to you via email after registering for the license

  • install VTune and profile the hell out of KDE/FOSS software and improve it all!

speeding up KDevelop

Personally I did the latter for KDevelop the last two days, and the results are astonishing. I just tested the results from today and an unscientific time kdevelop -s lotsofprojects - wait until parsing finished - stop showed roughly 50% decrease in time, from ~12min to ~6min. Yes, a whopping 50% - try it out for yourself and see how big the gain is. Don’t forget to whipe the DUChain cache though (i.e. via setting the environment variable CLEAR_DUCHAIN_DIR=1).

Why VTune rocks

I’m a huge fan of the Valgrind toolsuite, but it is simply too slow for profiling some things. Like opening ten medium to big sized projects in KDevelop and taking a look at the parsing speed. This can easily take a few minutes, but in Valgrind it would take ages. With VTune on the other hand, thanks to it’s sampling based approach, I don’t really notice the performance delay.

Then you might have heard of the new perf profiling utility in the Linux kernel. It is also sampling based, but sadly requires special compile options on 64 Bit (-fno-omit-frame-pointers), and the UI is horrible, I haven’t found anything worthwhile with it so far…

VTune on the other hand has an incredible GUI, which makes profiling a joy. You can look at call stacks top-down or bottom-up, visualize locks and waits, easily find hotspots, … I’m blasted. Especially the utilities to look at multi threaded performance (of e.g. KDevelop) kills every single other performance tool I have ever tested. Oh and did I mention that you can attach to an app at runtime, analyze some thing, and detach again?

Seriously, Intel: You just found a new fan boy in me. Thanks for giving this tool away for free for us “I hack on this tool in my spare time, yet still want it to perform nicely” people :) And kudos to the VTune developers - I’m blown away by it!

I really hope more people in the KDE community will try out VTune and try to improve the performance of our apps, I bet there is lots of potential!


There are some negative aspects to VTune though: First of all it’s UI is sometimes freezing. I wonder if the developers should not maybe spent some time on analyzing the tool itself ;-)

The biggest gripe though is that VTune does not work everywhere. I tried to run it on my Arch box, but sadly Linux 3.0 is not supported by VTune yet. It worked like a charm on two Ubuntu boxes with some 2.6.X kernel though.

This also means that I have no idea if, and how, VTune works on non-Intel CPUs. I think some of it works nicely. I did not install any of the Kernel modules for examples, which would be required for hardcore lowlevel CPU profiling. I think the same feature set I praised so much above, should hence be available on e.g. AMD CPUs. But well, this is left to be tested.

So, I’m now drinking a well deserved beer and look positively into the future of a fast KDevelop/KDE :)


» GSOC: C++2011 Support in KDevelop Part 1

Tue, 06/28/2011 - 14:09

Hey all,

I finally want to write a bit about my work on KDevelop during this year’s GSOC. To make things a bit more interesting for the whole crowd, even for those heretics that don’t use KDevelop, I want to highlight some C++2011 features I got to know in the process. Hence this multipart blog post should be interesting for all KDE hackers, as eventually we will be able to use these shiny new features of what is to be known as C++2011.

For those interested in the full overview of changes in C++2011, take a look at e.g. the C++0x Status Page in GCC 4.6, the wikipedia article on C++0x, or try to get hold of a copy of the C++2011 FDIS spec file. Note that the latter is apparently not freely accessible, see also this stackoverflow discussion. Still, maybe you find someone who can send you a copy…

So, lets get down to business. Following is a not-complete list of C++2011 features I’ve already implemented in KDevelop. If I mess something up in explaining a new feature, or if I forget an important aspect, please add a comment.

Range-Based for

This neat little addition is not so important to most Qt developers. We know and love our foreach macro. C++2011 comes with a similar built-in construct called range-based for. Essentially the syntax goes like this:

  1. QVector<MyType> list;
  2. for(const MyType& item : list) {
  3. // do stuff
  4. }

It’s neat, and very similar in syntax to the oldschool foreach macro. But there is a big difference: Where foreach makes a copy of the container, range-based for does not. This has mainly two implications:

  1. foreach is slow when used with containers that don’t use implicit sharing, most prominently STL containers
  2. range-based for has undefined behavior when you change the list you iterate over inside the loop.

Personally, I think I’ll stick to the foreach macro as it’s known to work well and has no big downsides in most Qt-based applications, as implicit-sharing is widely used throughout Qt.

RValue References / Move Support

This feature is a more advanced topic and mainly interesting for library developers who want to implement move semantics and/or achieve perfect forwarding, resulting in much better performance under certain conditions. Take a look at the Brief Introduction to RValue References, or the associated spec changes. From the syntax POV it’s just a matter of using && for rvalue references compared to the single & for normal lvalue references.

Defaulted and Deleted functions

This addition to the C++ spec is very welcome to me as it makes some code much more readable and also can be used to prevent hard-to-debug bugs or to improve performance. I’m talking about defaulted and deleted functions. E.g. from the wikipedia article:

  1. struct NonCopyable {
  2. NonCopyable & operator=(const NonCopyable&) = delete;
  3. NonCopyable(const NonCopyable&) = delete;
  4. NonCopyable() = default;
  5. };
  6. struct NoInt {
  7. void f(double i);
  8. void f(int) = delete;
  9. };

This shows the syntax of how to use this new feature. The advantages:

  • You can explicitly mark functions as deleted: Before you had to move these functions into private section of a class and not provide an implementation. When (accidentally) trying to use such a function you used to get unintuitive compile or linker errors. Now you get a nice message about usage of an explicitly deleted function.
  • You can prevent unwanted conversions: Using deleted functions is also useful when you want to prevent some function to be called with a different type that can be implicitly converted to your function’s wanted argument type.
  • Performance with defaulted functions: Compilers tend to write highly optimized code where possible. Implicitly defined constructors or assignment operators e.g. are one of these cases. But as soon as you use inheritance you (mostly) cannot use the implicit versions. Thanks to the new defaulted functions you can do that again. Furthermore it’s possible to change the access policy of an implicitly defined function (which are usually public) using the default syntax.
Variadic Templates

I confess that this is one of the more esoteric features of C++2011 for me. I never really did any serious template meta programming, and variadic templates are just as complicated as the other template programming. Yet I do see the advantages if people start to use it.

Anyhow, I implemented the required parser changes into KDevelop, but proper code completion and DUChain integration might need some time and brain effort :)


Now back to simpler things, yet definitely welcome and useful ones. One example are static assertions, i.e. compile-time assertions. The document I linked to contains a list of examples which should show how useful this feature is. Note that we Qt-users know and love the Q_ASSERT macro, but it is a runtime check. Boost users have had a BOOST_STATIC_ASSERT macro for some time, now we will finally be able to use it as well.

STL updates

Ah, before I forget it: Since KDevelop parses the STL includes, you should be able to use all new STL features already. If you spot a serious parser error in one of the include files of GCC 4.6 or 4.7, please notify me.

much much more

These are only some of the new features which I’ve added support for in KDevelop. I’ll try to sit down later today to write part 2, otherwise I’ll do that after I come back from the Fusion festival next week. Anyways, you can stay tuned for features like constexpr, opaque-enum-declarations, class-enums, improved right-shift token handling in nested templates, etc. pp.