GNOME Bugzilla – Bug 732151
High CPU and sluggish performance
Last modified: 2014-11-06 14:23:22 UTC
I was just trying gnome-music from master, and python3 was putting real strain on my machine - CPU usage was high and the fan was whirring. The Music app itself felt very sluggish and the performance of the rest of my system was affected. There was a bunch of output like this in the terminal (not sure if it's relevant): (gnome-music:5690): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed 12:16:03 WARNING albumArtCache.py:214 can't find URL for album 'Vocal Studies + Uprock Narratives' by Prefuse 73 12:16:03 WARNING albumArtCache.py:214 can't find URL for album 'World Dance: The Drum & Bass Experience' by DJ Hype 12:16:05 WARNING albumArtCache.py:214 can't find URL for album 'Xen Cuts (CD1)' by Amon Tobin (gnome-music:5690): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:5690): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:5690): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed 12:16:49 WARNING albumArtCache.py:232 Error: g-io-error-quark: Not Found (1) 12:16:49 WARNING albumArtCache.py:232 Error: g-io-error-quark: Not Found (1) 12:16:49 WARNING albumArtCache.py:232 Error: g-io-error-quark: Not Found (1) (gnome-music:5690): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:5690): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed 12:16:50 WARNING albumArtCache.py:232 Error: g-io-error-quark: Not Found (1) (gnome-music:5690): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed 12:16:50 WARNING albumArtCache.py:232 Error: g-io-error-quark: Not Found (1) 12:16:50 WARNING albumArtCache.py:232 Error: g-io-error-quark: Not Found (1)
The warning are from bug 727463 and unrelated to performance. I did a performance measurement lately and found two bottlenecks: 1) Artists is damn slow as we use many widgets and, most importantly, many tracker requests. We should minimize the amount of requests (handled in bug 729103) 2) Model's append and insert operations are very slow. We can try wrapping them in GLib.idle_add or batch them somehow so the UI will not get slowed down
Also, for first start / initial loading we should be less agressive when downloading albumart - afaik we're not limiting threads there, which hogs the machine for quite a while
*** Bug 732972 has been marked as a duplicate of this bug. ***
*** Bug 731992 has been marked as a duplicate of this bug. ***
*** Bug 731885 has been marked as a duplicate of this bug. ***
*** Bug 733991 has been marked as a duplicate of this bug. ***
*** Bug 736183 has been marked as a duplicate of this bug. ***
*** Bug 737614 has been marked as a duplicate of this bug. ***
I've pushed commit https://git.gnome.org/browse/gnome-music/commit/?id=665c2f673e179ceff0bcf8e8caa90b047c19308e, which should presumably please help a lot. Please comment if performance feels better/worse/same
I've tried it over and over and over... and for me, it makes no difference at all. I have 9000+ musics, and maybe this is overloading Tracker and/or GNOME Music.
I just launched Music for the first time on a new F21 install, and observed: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1442 aday 20 0 3077252 259248 48092 R 130.9 2.2 1:03.12 python3