Shockingly high CPU usage when scrolling listview [#14745]

[drakinite]

Dang, MM5 uses a lot of CPU for the listview. I did a performance analysis and it looks like the majority of time is being spent searching for track data (I see a ton of calls named bindData and getClassName that take a majority of scripting time), as well as multiple draw calls from ListView.parentScrollFrame per frame. Now, I've never developed any apps this complex, but my best guess for how to improve this would be to cache the track data so less time is spent retrieving it.

I always see isYoutubeTrack taking about half a millisecond because it runs a JSON.parse for every track for every frame, as well as a few other getValue calls that do extra processing that takes time. Also, the ListView header's vertical position is modified outside an animationFrame, which wastes 3ms of render time each frame.

Honestly, poking through all these callbacks was amazing, because I was originally expecting to see a few obvious bottlenecks that would be easily fixable; not a ton of complex code that all adds up in the long run. ^^; Anyways, I do think that the high cpu usage is an issue, and if it's possible to improve, it would be great. Having inexplicable surges of CPU usage is pretty bad, especially for folks with low end computers. Hell, even just mousing around the listview still brings my cpu up to 15-20%.

[Lowlander]

What node in the Media Tree and what View for the Filelisting are you using when you see this?

[drakinite]

Music node, and I'm using the List view. No album art thumbnails or anything.

[drakinite]

By the way, I should stress that a high CPU usage of the program is really bad for power usage on laptops. Literally all I have to do to get a CPU usage spike is to click onto MM5, then click on another program. It consistently spikes to 40% CPU usage for multiple seconds every time I click away from MM5 to any other program. Chromium's performance analysis shows me that it's doing garbage collection every time that happens, so it's probably something you can fix by tweaking the way it runs the Chromium engine. Discord and Visual Studio Code don't have that issue, and they use Electron, so it's definitely fixable, somehow.

[Lowlander]

Which exact build are you using?

[drakinite]

2258

[Lowlander]

This due to a combination of Chromium and more robust rendering, where Chromium uses a lot of resources: https://www.ventismedia.com/mantis/view.php?id=14745

[drakinite]

Hrm, Rusty and Jiri's comments are concerning. I don't think they read this thread at all- the fact that so much time is spent running JavaScript is very controllable from a development standpoint; and also, Visual Studio Code uses less than half the CPU resources when scrolling through UI (despite using the Chrome render engine). At maximum it ramps to 10-15% when scrolling and mousing over the UI. Or was this an old thread?

[Lowlander]

Yes, comments are from 2018.

[Ludek]

isYouTubeTrack taking about half a millisecond is not the issue. It could be one of many minor optimizations, but we can't expect any significant improvement (as Jiri wrote).

CPU is higher even when just hovering mouse where our functions takes only micro-seconds: https://www.dropbox.com/s/c3rz72chn5pm6 ... 0.png?dl=0
That said it is rather the Cromium rendering taking the CPU resources, we can certainly try to optimize it "somehow" as we already tried in the past, but it won't (and cannot be) like with MM4 just because of the another technology and CSS animations used (which are known to be CPU intensive).

[drakinite]

Okay. Man, that's a really big shame considering battery life on laptops. But okay.