speed improvements (patch)

[Ovidiu Gheorghioiu]

Hi all -- particularly devs.

Recently Amarok has been getting slower in handling my increased
collection size -- and increased usage.

So I loaded it up into callgrind and started eliminating whatever
inefficiencies I saw that had significant effects on the running time.
The easiest targets were critical-loop string copying and growing,
which is what this changelist is mainly about.

I can keep doing optimizing, as time allows, if you guys think it's
OK. I'll try not to touch code that is not a proven performance
problem.

A summary of changes in this patch:
* allocate column name qstrings statically in
MetaBundle::exactColumnName. This turned out to be a big drain on the
startup playlist load
* my pet peeve: playlist searching. I use this a lot. So I added an
optimized path which causes no per-item mallocs except the first time
around, or until the set of columns changes or a visible item changes
value.
* also, on the optimized path, dynamic values extracted from the db
such as rating are not searched. The reason is that loading them up
will hog the GUI thread by going to the database a lot on the first
search after a playlist load. This is probably the biggest reason I
started this work at all. Try displaying ratings and doing a search
right after startup to see what I mean. It seems to me like nobody
would actually type 5 to search for rating 5 songs, or 95 to search
for songs rated 95. Searching by operator rating 5 still works, with
the requisite slowdown. I can address this sometime, but it won't be
as easy.
* the query builder gets called a lot during startup to build the
smart playlist tree. it was very inefficient at concatenating strings
and ended up reallocating a lot, for about 12% of startup time. Now
it's almost gone.

Further areas I could work on:
* I'm pretty sure the smart playlist stuff can be built with O(1)
queries. It's a couple of seconds of startup time right now, and maybe
some time from "Updating collections".
* searching can be made O(Nmatching + Lquery) with a good index. But
this is heavy work and I'll need a bigger chunk of time to do it.
* misc slowdowns I notice in the UI
* misc callgrind targets

Regards,
Ovy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: speed-1.patch
Type: application/octet-stream
Size: 19330 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061003/18502c61/attachment.obj>