Hello my GNOMEish friends!
This afternoon, I felt an urge to hear some classical music. Perhaps because I’m overworking a lot these days, I wanted to grab a good hot tea, and listen to relaxing music, and rest for a few minutes.
My player of choice is GNOME Music.
In the past, I couldn’t use it. It was way too slow to be usable. After a round of improvements in a sleepless night, however, Music was usable again to me.
But it was not fast enough for me.
It was taking 15~20 seconds just to show the albums. That’s unacceptable!
The Investigation
Thanks to Christian Hergert we have a beautiful and super useful Sysprof app! After running Music under Sysprof, I got this:
Clearly, there’s an area where Music hits the CPU (the area that is selected in the picture above). And, check it out, in this area, the biggest offenders were libjpeg, libpixman and libavcodec. After digging the code, there it was.
The performance issue was caused by the Album Art loading code.
The Solution
Looking at the code, I made a simple experiement: tried to see how many parallel lookups (i.e. asynchronous calls) Music was performing.
The number is shocking: Music was running almost 1200 asynchronous operations in parallel.
These operations would be fired almost at the same time, would load Zeus knows how many album covers, and return almost at the same time. Precisely when these lookups finished, Music had that performance hit.
The solution, however, was quite simple: limit the number of active lookups, and queue them if needed. But, limit to what? 64 parallel lookups? Or perhaps 32?
I needed data.
The Research
DISCLAIMER: I know very well that the information below is not scientific data, nor a robust benchmark. It’s just a simple comparison.
I decided to try out a few lookup limits, and see what works best. I have a huge collection, big enough to squeeze Music. I’m on an i7 with 8GB of RAM, 7200RPM spinning hard drive.
It was measured (i) the time it took for the album list to show, (ii) the time for all album covers to be loaded, and (iii) a quick score I made up on the fly. All of them are of the type lower is better. I ran each limit 10 times, and used the average of the results.
The “No Limits” columns represent what Music does now. It takes a long time to show up, but the album covers are visible almost immediately after.
First conclusion: limiting the number of lookups always performs better than not. That said, the problem was just a matter of finding the optimal value.
After some trial and error, I found that 24 is an excellent limit.
The Result
In general, the initial loading of albums with the performance improvement is around 73% faster than without it. That’s quite a gain!
But words cannot express the satisfaction of seeing this:
Enjoy!!
Leave a Reply