GNOME Bugzilla – Bug 603661
Banshee uses a lot of CPU
Last modified: 2010-03-22 16:03:56 UTC
This is what happens: 1. I start banshee. No problem there. 2. I start a song. CPU remains normal (around 15% on my machine) 3. I switch to another song. Depending on my luck CPU rises to 65% - 195% 4. Switching to another song always brings CPU usage to 195%. From this moment on, switching to another song using any method (selecting in the list, using next/previous, end of song) brings CPU to 197% and the GUI hangs. I think this is caused by the size of my library. When I import half the songs (about 2000 songs), CPU usage is around 70% and GUI is going slower but it is not hanging. If I remember well, version 1.4 did not have this problem.
This issue is related to bug 581103. Marking it as dependent on it. Patch is coming...
To make sure that's the case, could you run banshee from terminal, switch songs a couple of times and attach the log file? $ banshee-1 --debug-sql > log.txt
Created attachment 148983 [details] debug log generated by running banshee with the --debug-sql option I have been having similar issues with performance. My library contains ~7600 songs and no videos. I have attached a debug-sql log.
Created attachment 148993 [details] Debug log from 'banshee-1 --debug-sql > log.txt'
I added a patch to the bug 581103 which should fix this issue as well. Please test: attachment 149074 [details] [review]
I downloaded the code from the GIT repo and applied the patch. There seems to be an improvement. Normal use of Banshee makes CPU usage go to a maximum of about 100%. Fast switching between songs still drives CPU usage up to 160%. I was wondering... Is there a way to tell Banshee to use a different DB engine? For example MySQL or so? Thanks for the patch !
I committed the patch and closed the bug this one depended on. Regarding switching to another DB engine, I'm not sure there's anything much faster than sqlite. Even if there is, I doubt any active developers would want to work on this. It would be a major undertaking and there are plenty of more important bugs and features to work on. I'm going to close this bug. Short spikes in CPU usage during song changes are normal and expected: we do need to recalculate smart playlists when playcounts and timestamps change. Feel free to re-open if any of the queries still run longer than ±500ms.
Created attachment 151382 [details] Banshee run with turned on for CROSS JOIN debugging With CROSS JOIN turned on, switching songs results in 24000+ms delays and GUI locking. I've reverted the patch and updates average <100ms. SQL 2.8.17 and 3.6.16 currently installed on Ubuntu Karmic
Kevin, could you run these two commands in terminal and paste the output? $ sqlite3 ~/.config/banshee-1/banshee.db ".schema CoreTracks" $ sqlite3 ~/.config/banshee-1/banshee.db ".schema CoreSmartPlaylistEntries" Thanks!
Created attachment 156185 [details] CoreTracks schema
Created attachment 156186 [details] CoreSmartPlaylistEntries schema
(In reply to comment #11) > Created an attachment (id=156186) [details] > CoreSmartPlaylistEntries schema Hmm, you are missing this index: CREATE INDEX CoreSmartPlaylistEntriesIndex ON CoreSmartPlaylistEntries(SmartPlaylistID, TrackID); Could you create it and see if that fixes it?
Alexander: Wow! Significant speed improvement. Adding that entry certainly fixed it. Thank you.