View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017775||MediaMonkey 5||Main Panel||public||2021-04-20 17:57||2021-04-27 19:48|
|Summary||0017775: Performance bottleneck - SharedList.prototype.isSelected is slow|
|Description||I spent some time analyzing the performance of ListView, and found a minor performance bottleneck that probably should be optimized. When scrolling in large grid views, the native method "this._dataSource.isSelected(item)" is responsible for adding ~3-5ms per frame. There may be some poorly optimized code inside the native isSelected method, leading it to be slow.|
|Tags||No tags attached.|
|Fixed in build|
How did you measure this? I mean, in the past I got some measurements that were a bit confusing and it's often hard to come to conclusions wrt to js<->native code interactions timing. Would definitely like to find out more about it.
Anyway, looked into isSelected and it seems to be as trivial as possible.
I measured it by adding a bunch of timing metrics to the draw_locked function in listview.js. To measure the timing within the main loop, I made a "timeDiffs" array which sums up the total amount of time from the start of the iteration up to that point. As you scroll, it'll console.log the timing. The "count" it prints is the number of times it calls isSelected(item). In most views, I've found that timeDiffs is multiple milliseconds when the current view is selected (i.e., if you have the Albums grid view open, click on the grid viewport itself and scroll up and down). It's especially bad when you open an album with dozens or hundreds of tracks (I have a "SoundButt Likes" album which has over 600 tracks).
When it comes to something that should ideally be running at 60 fps (17 ms), 2-5 milliseconds is a lot.