optimization proposal -- playlist stored in the DB
Maximilian Kossick
mkossick at gmx.de
Fri Oct 6 08:28:16 UTC 2006
On Friday, 6. October 2006 09:41, Ovidiu Gheorghioiu wrote:
> Hi guys,
>
SNIP
>
> I think having the playlist in the DB would eliminate these issues.
> Loading would definitely be faster, as can be seen from the smart
> playlist loading time (1.1%in SqlLoader) -- and the smart playlist is
> actually a fairly complicated query. Saving will likely be much faster
> too, and most importantly it can be done incrementally for things like
> undo or autosave.
I agree.
> And there are other fringe benefits, too. For example, another 6% was
> spend loading song ratings one by one as I was scrolling, on the first
> instance of the playlist which came from XML -- these can probably be
> stored right in the playlist table.
That can be solved relatively easily by not lazy loading the song scores and
ratings. At the moment, CollectionDB only loads the actual song tags when
creating a new MetaBundle. It should be possible to add a join on the
statistics table and read the song score and rating without a performance
hit. The song scores and ratings are stored in XML when they are available,
too.
> So, what do you guys think? I'd be willing to do a significant amount
> of the work, but I would likey need / use some help from somebody
> who's familiar with the DB. And also some testing on the other two
> db's, which I don't have installed or configured.
Ask here or (better) in our IRC channel. It should be possible for you to
stick to standard SQL which works on all supported databases. Somebody will
usually complain in #amarok within a few minutes of your commit if the SQL is
broken;)
> Regards,
> Ovy
Cheers, Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061006/6e1c9f0a/attachment.sig>
More information about the Amarok
mailing list