speed improvements (patch)

[Seb Ruiz]

On 04/10/06, Ovidiu Gheorghioiu <ovidiug at gmail.com> wrote:
> 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
>

Hi Ovy,
Firstly, I'd like to thank you for the time and effort you put into
this patch - there certainly are a lot of insightful thoughts which
you have clearly put into the code!

I can't see a reason to not commit this, but we should wait until some
of the other developers have had a good read.

Secondly, you seem keen to be able to provide us with more patches,
and we would be thrilled to have someone help us out with optimising
the applications.  The slow downs are certainly one of the worse parts
of Amarok.  If you wanted to do any work with us, you should join us
on the IRC channel - it is where all of our development chat happens.
details: irc.freenode.net #amarok

Looking forward to more of your patches!
Seb

-- 
http://www.sebruiz.net/