extragear/multimedia/amarok

[Martin Aumueller]

Good, we're almost there: loading the same set of files, again with cold 
caches, took 65 seconds this time - with current Amarok. That's quite an 
improvement, but perhaps there is still some room for optimization.

BTW, I had to enable fixHyperthreading() for being able to test this, as 
Amarok has become a lot more crashier since yesterday.


On Tue July 25 2006 03:14, Jeff Mitchell wrote:
> > However, this is a valid issue and I will think on it.  I have to do some
> > thinking and some code tracing to tell whether or not filling in the
> > MetaBundle value from the database if the url exists there is going to
> > cause problems or not.  I'd like to say it is a good idea and will work
> > beautifully (I think so), but give me a bit of time to look into it.
>
> Okay.  Having looked through my often-changed and scratched-out notes, it
> seems like the reason that setUniqueId always reads the files is because
> when I was originally working on it I didn't yet have all the slots in
> playlist.cpp and functions in collectiondb.cpp that I needed so it was the
> only way while I was testing to ensure that I always had the uniqueid
> filled in.
>
> And then, until Martin and Alexandre brought it up, I completely forgot
> about that fact :-)
>
> So having looked at it and thought about it I think that we can do a
> database query on the metabundle's url as Alexandre suggested and if it
> exists use that.  I don't think there are any corner cases where that won't
> work but if so they'll be rare.  I'm going to do that here and do some
> testing, and if all goes well I'll commit.
>
> Martin, when I do, if you could re-run your test with the same 6300 files
> it'd be great.  Chances are it'll still be a bit slower due to the extra
> database queries, but probably faster than reading the tags with TagLib
> (and not having the same issues that could potentially cause taglib to
> bring down amarokapp).  If we can remove or change any code that fills in
> MetaBundles instead of creating new ones, we could probably avoid many or
> at least some queries, but that may cause slowness elsewhere.