Escrúpulos Una piedra en la conciencia del software libre, calidad y la vida misma

Yesterday I finally upgraded my Kdemod setup to 4.5.0. First of all, it rocks! Second, we hit a nasty problem in KMyMoney that might have delayed the whole release tomorrow. KMyMoney took over 2 minutes to start after the upgrade. Normally, it took 2 seconds. Also, it was using 10 times the amount of RAM.

We've been in critical freeze since Friday, meaning only critical bugs are allowed in. This certainly qualified as critical, so I got down to business. First, send an email to the list, looking for someone else to confirm the problem in 4.5. Second, compile from scratch, and try to find the cause of the slowdown. Using the application didn't throw any conclusive, except it was somewhere in forecast. Forecast does some weird calculation, but the code has been pretty much stable for over a year.

Talking to Thomas on IRC, he pointed me to cachegrind. So, I installed valgrind (I already had KCachegrind), and ran kmymoney with cachegrind.

$ valgrind --tool=cachegrind kmymoney

About an hour later, KMyMoney finally finished the startup process and I quit it. Looking at the log left behind by Cachegrind.

The log actually showed a huge amount of RAM used by Unknown, which wasn't very useful. Back to square one, use callgrind to find the offending call.

$ valgrind --tool=callgrind kmymoney

This time, the log had more useful information. KCachegrind showed an insane amount of time was being spent in libkholidays. An empyrical test showed that changing forecast to not call the holiday methods almost vanished the problem.

So, a mail to John Layt later uncovered the problem in a method of HolidayRegion which was not meant to be used the way we're using it in KMyMoney. Implementing the solution suggested by John solved the problem completely. We had to go back and forth with the fix a few times, though. Some of the methods are KDE 4.5-only, so the workarounds had to be applied accordingly.

We think the problem is finally fixed. Thanks to valgrind and KCachegrind. And of course to the rest of the team that quickly jumped in to help.