Archive for November, 2006

KOffice 1.6.1

29 November, 2006 Leave a comment

The first bug fix release of KOffice 1.6 is out. With a lot of bug fixes in all the applications, and mostly kexi and krita which were the most actively developed in the 1.6 cycle. This version also include a few new features like a color level filter for krita, or a new combo box for database relation ships and parameter queries in kexi.

But what a difficult release it has been to do.

My experience at releasing software for a wide public started in May last year with krita-plugins, and I think I have screwed all of them. I did create the tarball by hand and attempt to clean them of all what I thought was unnecessary. It turns out that the package was around ten times too big. So someone suggest me to use some “scripts” that would help me. Well my experience with the scripts for releasing KDE software has been a hard reminder of “never trust blackbox”, the problem is they are written in “shell script”, and I have always believed that shell scripts of more than ten lines are written in the wrong languages, so I did give up on understanding them.
But I sill did use them.
For 1.6 Alpha, Beta 1 and RC1, I thought everything had work fine, so I was happy. Wrong. The build system was initialized in none of them. Which makes me wonder, how many people do test pre-release software ?
For 1.6.0 I found where was the problem, I was using (like my predecessors) the script of KDE/trunk, until 1.6, it was perfectly fine, but at the same time, the KDE4 team decided to start releasing developer version of KDE4, and did adapt the scripts mostly changing the initialization of the build system.
So for 1.6.1, I decided to be clever, and use the scripts from the 3.5.5 branch. What a mistake. Those scripts were too old for KOffice ! And I end up with an unwanted translation file and with kplato gone from the source tarball. A little bit unrelated to script problems, but that did explain why the delay of 1.6.1 was so big, when we were ready to write the announcement and make the release, someone found a security issue in the powerpoint filter.

Hopefully, I think I have found a version of those scripts that should work fine for the last release of the 1.6 cycle. I say “Rendez-vous in a month and an half” !

Fast startup with valgrind

27 November, 2006 Leave a comment

Thanks to Frank and Thiago for giving me that tip: if you are not interested in profiling the startup of your application, just launch valgrind with –instr-atstart=off, and then reactivate profiling, with “callgrind_control -i on”.

This will make startup be ten times faster, and on positive note, it will give you cleaner outputs.

A practical exemple of optimization : krita’s loading (developement version)

26 November, 2006 Leave a comment

It’s really easier to blame the hardware for the slowness of your software, and to sit idly while the law of Moore increase the speed of computers. On the other hand it’s also easy to track little mistake that can considerably boost your program. The other I made a brief overview of all the available tools, today I will tell about a practical session of optimizing.

A few days ago Casper came on irc and sayed that krita’s startup in trunk was really slow. Which was true, so I launched sysprof then krita, and I noticed that the CPU did spend half of its time in the gradient loading code, and more precisely on creating KoColor objects.

Lets have a look at the code of the function KisGradient::generatePreview, in which there is mostly a loop creating an image:

for (int y = 0; y < height y ++)
for (int x = 0; x < width; x ++)
KoColor c

So lets try to move “KoColor c” out of the loops, and see what happen. The result is as expected, the startup is down from around 8 seconds to 4 seconds as the next screen shot of sysprof confirms:

Now costs are less spectacular but it’s still possible to do a lot of optimization for a small amount of effort.
The function KoColorSpaceRegistry::rgb8() is creating the color space strategy for RGB 8bit images, but there is no need to create a new object at each call, they can be shared, so lets use cache it as a member of HSVCCWColorInterpolationStrategy.

As you can see on the screenshot HSVCCWColorInterpolationStrategy::colorAt is not anymore the most expensive function, now it’s RGBColorInterpolationStrategy::colorAt. Unfortunately mixColors is allready a pretty much optimized function and we will have a hard time to spare CPU cycles in it (unless trying to use MMX instructions).

But as we can see the creation of KoColor object is once again costing us a lot of time, unfortunately it won’t be as easy as for the first time, as we need to change the API. Instead of having function retuning KoColor objects, I just pass to the function a reference to the KoColor object.

So indeed, “premature optimization is the root of all evils” but if you start might have to do it before your API is frozen. At least to keep it clean from DEPRECATED flags.

Note, that this was in new code for Krita 2.0, so nothing much to gain for the 1.6 serie 🙂

I am starting a wiki page on koffice’s wiki about optimization of krita the goal is to create a list of all the tips to improve the speed of krita.

The tools to optimize your application

25 November, 2006 Leave a comment

“Premature optimization is the root of all evil” is probably the most respected rule in the development of Krita. But now that we have made three major releases, and even if the development version is under heavy refactoring, most of the framework is in good shape, and now is time to start optimizing. Which is something on which I have started to work actively in September, after the feature freeze for 1.6, some new progress will be included in the upcoming 1.6.1 (mostly in the convolution code, the painting, and gradients).

Optimization is divided in two tasks, the first one is to find where you code is slow (and most of the time it’s not the function you expected to be slow which cause you problem) and the second one is to find how to remove the slowness. And to accomplish those two tasks you need some proper tools, for the second task, it’s your brain, but for the first one, there is a lot of possible solutions, divided in three categories:

  • tools which requires special compilation option mainly it’s gprof, which is annoying to use as you must recompile your code with the “-pg” option which slow down your program, on the other hand the results are accurate and reproductible.
  • valgrind is a virtual machine and therefor is very slow to execute, and the main tool for optimization is callgrind/calltree which in fact counts cache misses, while it gives an account of where your code is spending time, it’s not accurate computation of CPU cycles, on the other unlike gprof you don’t need to rebuild your application just for profiling, and unlike oprofile and sysprof, the results are reproductible, which means that you can take the output for two different implementation, and you will know which one is faster.
  • kernel module which measures CPU cycle consumption, the two I know are oprofile and syprof, both work by inserting a module in the kernel which will make measurement of how many cpu cycles are spend in a given functions, the main advantage is that your application run at its normal speed, but the problem is that it is an experimental analysis, therefor the results are not reproducible, as they depend of how many measurements the kernel module was able to run, which means you can’t use them to make a comparison between two implementations, and small and fast functions but which are called a lot and therefor are expensive might be unnoticed by the module. The difference between them is that sysprof offers very basic functionalities but is very easy to use (which are accessible through a GUI as shown on the screenshot below) while oprofile is a very powerful tools but difficult to master

sysprof in action on krita

If you have heard of an other profiler for linux with which you had a good experience, I will be more than happy to hear about it.

I have been a long time user of valgrind until recently, my main issue is the speed, especially with krita, it can takes ten minutes to load when all plug-ins are installed. Because of that, now I am mostly using sysprof unless I need to compare two implementations, in which case I fall back to valgrind.

In a next blog entry, I will speak about a practical example of using sysprof.


5 November, 2006 1 comment

I have been thinking for a long time about a replacement for my old dying mascot, a vectorial happy chap with raising hand, which I used in the new skin for my web site that I have been developing for the past four years, but never find the time to finish, in other word, I wanted to replace a vapor-mascot. And today I figure out that a sheep would be a cool mascot, so I think my dreams and drawings will be filled with sheeps this days. And what better start for this, than trying watercolor ?

That’s it for a nice water-sheep.