Bugzilla – Bug 9194
Track::artist expensive; suggest cache result and avoid double calls
Last modified: 2009-10-05 14:32:03 UTC
The Slim::Schema::Track::artist() call is reasonably expensive and called very often (for example from _addJiveSong - see bug 9189). It probably makes sense to add a new column to the Track table and either fill this as part of the scan or lazy-evaluate it as part of the call to artist(). Also, Track::artist() is often called in a manner such as: if (blessed($obj->artist) && $obj->artist->name) { $track->creator($obj->artist->name); } or blessed $track->artist ) ? $track->artist->id : undef Sometimes there are multiple such calls in the same function. It would probably help to call such object-generating methods only once. Similar comments apply to Track::album(). For example, blessed $track->artist ? $track->artist->id : undef could probably be replaced by: $track->albumid
Alan: Seems like a reasonable optimization for 7.2.1, or were you thinking this is further out?
Sre, it could go in 7.2.1. I would need some help from someone more familiar with the DB stuff.
Are you thinking of a string containing the formatted list of artist names or a column containing contributor ids? Either way, it will likely be challenging to maintain database integrity with respect to the contributor_track table. If this is done (and proves to be useful), then it makes sense to also do it for albums, where retrieving the artist(s) for an album can be an expensive operation that has a lot of impact on performance when browsing albums in the web ui.
I'm looking at the following from Schema/Track.pm: sub artist { my $self = shift; # Bug 3824 - check for both types, in the case that an ALBUMARTIST was set. return $self->contributorsOfType('ARTIST')->single || $self->contributorsOfType('TRACKARTIST')->single; } This only ever returns a single Artist object, somehow designated the "primary" artist for the track. This is a very common query, where various UIs and status functions want "the" artist for a track (you could argue that this, in itself, is wrong but that is a separate issue). It would seem to be efficient to cache, in the Track table, the resulting artist-id (primary key to Artist table), so that this (expensive) search need be done only once.
This doesn't seem likely to go into 7.2.1.
Change 26358 makes the following improvements: Add Track::artistName() as helper method and use when appropriate. Use Track->albumid in favour of Track->album->id. Remove other repeated indirection via Track->artist or Track->album. Still want to consider adding a column to cache artistid in Track.
Created attachment 5197 [details] Cache primary artistid in Track column I could not make this work by adding a schema_9_up.sql, so this change would require a wipe and rescan. It makes a big difference to the speed of Jive playlist queries.
For 7.4 I think a wipe is fine, as they will have to do a full rescan because of the move to SQLite anyway.
Changes 26614 & 26615 implement the cached primary artist concept and some utility accessors.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.