Bug 15779 - Optimize performance of statusQuery/_addJiveSong
: Optimize performance of statusQuery/_addJiveSong
Status: CLOSED FIXED
Product: SB Touch
Classification: Unclassified
Component: TinySC
: unspecified
: Other Other
: P1 normal (vote)
: 7.5.0
Assigned To: Andy Grundman
:
Depends on:
Blocks: 15796
  Show dependency treegraph
 
Reported: 2010-02-25 11:30 UTC by Andy Grundman
Modified: 2010-04-08 17:26 UTC (History)
3 users (show)

See Also:
Category: Task


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Grundman 2010-02-25 11:30:43 UTC
These methods were never optimized and are still using very slow DBIC calls. 
Needs optimized in the same was titlesQuery/_addSong was handled.
Comment 1 Chris Owens 2010-03-01 09:24:22 UTC
Andy notes this may be related to the very slow TinySC performance we are currently seeing.  Andy notes this bug is safe due to the ease of writing tests to verify the fix.
Comment 2 SVN Bot 2010-03-02 02:59:01 UTC
 == Auto-comment from SVN commit #30292 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30292 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
Try really hard to use the Schema::contentType cache as efficiently as possible.
Comment 3 SVN Bot 2010-03-02 03:30:50 UTC
 == Auto-comment from SVN commit #30293 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30293 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
The fixes for bug 15456 extended the detail of the 'artist' value returned _addJiveSong()
by considering each of the albumartist, trackartist and artist roles, instead of just the
track primary artist. This, and the consequently required use of the 'A' tag to _songData(),
is very expensive - too expensive on any sort of slow system or with a large playlist.

_addJiveSong() had previously been optimized to use only the track primary artist value on the
basis of similar observations.

This change keeps the changes from bug 15456 only for current track (the playing track). Other
tracks in the playlist only get the primary track artist information.
Comment 4 SVN Bot 2010-03-02 05:50:56 UTC
 == Auto-comment from SVN commit #30295 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30295 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
Fix problem with artist for remote tracks.
Comment 5 SVN Bot 2010-03-02 07:42:44 UTC
 == Auto-comment from SVN commit #30297 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30297 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
Optimize calls to Track::remote & Track::id.
Comment 6 Alan Young 2010-03-02 08:25:29 UTC
After the changes above, about 50% (with a 12-item playlist) of statusQuery is consumed by this loop from _songData():

				foreach my $type (Slim::Schema::Contributor::contributorRoles()) {
						
					my $key = lc($type) . $postfix;
					my $contributors = $track->contributorsOfType($type) or next;
					my @values = map { $_ = $_->$submethod() } $contributors->all;
					my $value = join(', ', @values);
			
					if (defined $value && $value ne '') {

						# add the tag to the result
						$returnHash{$key} = $value;
						$returnHash{"arrayRef_$key"} = \@values;
					}
				}

Some optimization would be great.

The only other significant call is to stillScanning() (c. 2.5%)
Comment 7 SVN Bot 2010-03-03 00:20:35 UTC
 == Auto-comment from SVN commit #30310 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30310 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
Tidying: encapsulate use of _songDataFromHash() within _songData().
Comment 8 SVN Bot 2010-03-03 19:34:21 UTC
 == Auto-comment from SVN commit #30322 to the slim repo by agrundman ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30322 ==

Bug 15779, convert stillScanning to native DBI as it's called a lot
Comment 9 SVN Bot 2010-03-05 08:23:26 UTC
 == Auto-comment from SVN commit #30337 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30337 ==

bug 15779: Optimize performance 
Avoid unnecessary joins when adding an album to the playlist.
Comment 10 SVN Bot 2010-03-05 09:08:08 UTC
 == Auto-comment from SVN commit #30338 to the slim repo by agrundman ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30338 ==

Bug 15779 (sorta), keep track of changes made to the DB by the scanner and optimize the DB after every 100 changes. Add ANALYZE command for SQLite optimization, slow but necessary
Comment 11 SVN Bot 2010-03-05 14:43:53 UTC
 == Auto-comment from SVN commit #30340 to the slim repo by agrundman ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30340 ==

Fixed bug 15779, refactored native DBI used by titlesQuery so it can be used by both titlesQuery and statusQuery
Comment 12 SVN Bot 2010-03-07 02:05:16 UTC
 == Auto-comment from SVN commit #30345 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30345 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
Create Playlist:songs() to get a range of tracks from a Playlist.
Need to allow for the possibility that a playlist may contain tracks that are no longer in the RemoteTrack LRU cache.
Comment 13 SVN Bot 2010-03-07 02:15:17 UTC
 == Auto-comment from SVN commit #30346 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30346 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
Protect against not being able to get a Track object for an item in the playlist.
Comment 14 SVN Bot 2010-03-08 01:39:18 UTC
 == Auto-comment from SVN commit #30348 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=30348 ==

bug 15779: Optimize performance of statusQuery/_addJiveSong 
Ensure that Playlist:songs() only returns valid objects, 
and it updates the playlist with objects when URLs are found.
Comment 15 Chris Owens 2010-04-08 17:26:17 UTC
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!