The Overhead of KDE Software

When Calligra 2.4 was released there was a flurry of interest resulting in a number of articles in the press and blog posts. Some of these were regular reviews of higher and lower quality. One of them, which I think was one of the better ones, was this one by Påvel (in Swedish). In the review he says that Calligra has a good foundation, he likes it but there are obvious problems with it. I find that an honest and true assessment, especially since it is obvious that he has really tried it and been bitten by some bugs. (Some of these bugs are already fixed in 2.4.2, most of the rest will be gone in 2.5.)

But that is not the topic of this blog post. In one paragraph he says that "since it is a KDE program it will work best in that environment." and offhandedly states that "In Gnome it will drag in a couple of hundred MB as KDE dependencies". I found that unlikely, given all the work that we in KO GmbH have done on Calligra for embedded platforms but I know that there is some overhead involved. But how much is it?

So I asked in #kde-devel on irc if anybody had done the measurements to say how big the overhead of KDE applications is in a non-kde environment. It appeared that nobody had done that, or at least nobody knew about any figures.  But I managed to trigger the curiosity of Michael Pyne enough so that he immediately decided to check it.

He started up his trusty Fluxbox environment and did a continuous measurement of the free memory (taking into account buffers and cache) and found out the following:

When a KDE application is started in a non-KDE environment the memory goes up (of course) and when it is killed again the memory goes down. The memory that remains used is probably the KDE overhead in the form of libraries (Qt and the kdelibs) and daemons (kdeinit4 and kded4). This overhead is 48 MB.

Michael also said that he found that it took "102084 1KiB blocks of memory to run konqueror, konversation, + associated KDE daemon procs in fluxbox." That figure includes everything: the Qt runtime, kde libraries and the applications themselves and is a very low figure for what you get.

As a side note, you will get the same overhead when you run e.g. Libreoffice on your desktop since they have their own toolkit. The difference is that that toolkit is not used anywhere else in any other application.

So, there you have it. Admittedly this is very unscientific but 48 MB is significantly below 200 MB, so much that the 200 MB figure can easily be dismissed. And even when you include two applications and all the toolkits and libraries it still hardly goes over 100. So until somebody takes a more scientific approach I will state that the KDE overhead in a totally non-kde environment is 48 MB.

Bug Week for Calligracommon

Three weeks ago Calligra developer C Boemann suggested that we should have a bug week for the parts of Calligra that don't have their own maintainer to nurture them, namely the common parts. These are core libraries and plugins that are used in all the applications and therefore very important. A bug here makes all Calligra applications worse.

In Calligra we have a policy that says that each application should have a maintainer but the common parts should not. This emphasizes the needs of the applications rather than the wishes of the maintainer and it has worked very well for us since we instigated the policy.The downside is that there is nobody who is really responsible for them; the responsibility of all is the responsibility of none.

The idea was to focus on the common bugs for a week. This last week was the week that was chosen, and now the results are in. To see the common bugs, you can use one of the reports on bugs.kde.org: https://bugs.kde.org/component-report.cgi?product=calligracommon. As you can see, there are no more known bugs for the picture shape (flake-picture) and no more for the color engine (pigment).

The bug week excluded embedded documents, which are not supported at all in Calligra at this point, and everything that has to do with text, which actually has a maintainer. The rest of the components went from 192 bugs down to 95. I find that pretty impressive!

Another way to see what has happened is to look at the Weekly bug statistics. Despite the name you can see the number of bugs and the change in bug statistics for any period of time. This link shows the change in bugs for the Calligra common product (you have to scroll a bit down to find it) and for the 3 weeks since the bug week was suggested. There was a lot of focus on these bugs even before the actual bugweek so I include the whole period. The results are:

• For bugs: +7 -70
• For wishes: +2 -43

This means that around 100 bugs and wishes were fixed or implemented in the 3 weeks. The actual numbers are slightly higher but not everything was fixed. There were a couple of wild dreams which we found weren't really right for bugs.kde.org and there were some bugs that weren't really common after all.

But in general I think we can pronounce the Calligra Common Bug Week an astounding success!