So Carsten was complaining about adept filtering being slow. And told me that it could use callgrinding. I was pretty reluctant to do that since i know it takes ages. Well, after trying some ad-hoc optimisation and primitive profiling, it turned out that the data is almost random — depending a lot on X server interaction and stuff like that. And the optimisation i came with was still sort of useless.
So okey, i bit the bullet and ran it in callgrind. Half an hour later, i had a a profile that i loaded into kcachegrind. As usually, i was lost for few minutes, but then it started to make sense. And, umm, there was a culprit… I would never actually think that this particular piece of code would be the bottleneck. This just confirms, as usually, that half hour spent profiling is better than half day optimising without a profiler. The net result is, that i really need oprofile. Doing optimisation work with callgrind is useful, but frustrating. Half an hour to get some data, laptop went to some 74 degrees Celsius etc. Blah.
Anyhow, back to what profile revealed. 17% of time spent retrieving package status. Wow, well, that’s bad. There, it could be expected it would show up on profile, but this is really a lot. The idea is, that the filter is a boolean expression (using operators and, or, not) and using “atomic” predicates about the packages, like: isInstalled, isUpgradable, there are some to match package name and so on. So the “state” filter you can see on the top of adept window is made as a (foo or bar or baz) and (wibble or wobble or bubble) with the right predicates (i can’t recall them right now). And every and each of those predicates asks for state. For every package. All fine.
That’s sort of intended and not optimised in some manner because “premature optimisation is root of all evil”. The problem is, that querying state involves looking up the “state component” in a std::map by a string retrieved from typeid of the state component. Owgh. I always knew it was bad code. It is removed in my development tree of the code (which however doesn’t quite compile so far). So the state retrieval itself is lightning-fast compared to getting a pointer to the “state component”.
Conclusions? I identified an important source of slowness in the adept filters. Even before doing the profiling, i have changed the code in development branch. So i knew it was bad. And the filtering performance would probably improve visibly when i am done porting the Adept GUI, even without the profiling exercise. But probably, i would be left in the dark on why exactly the performance improved. So if nothing else, it was a learning experience :-). And finally profiling proved itself to me. So, new motivation to spend time on getting oprofile working…