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

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.

This entry was posted in Krita, Open Source and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>