Rendering a large SongList hangs the renderer

[Siri-chan]

Searching for a large query, like ' (which will get the whole library, since the search bar strips the character out) is incredibly slow, despite the MPD query happening pretty quickly.

I was fiddling to see how easy it would be to speed up large searches (as above) a bit, since this project seems like something I'm definitely interested in, but my large music collection was causing a lot of slowdown.

I implemented (Siri-chan/Vermilion@aee20da) a dead simple cache (literally just using a Map) and thought I should benchmark it against not caching results, even though the improvement was pretty marginal.
It turns out, actually talking to MPD only takes about 8ms - even without caching - but somewhere else along the way¹ the program hitches for a second or more after actually retrieving the song list.

Any idea what might be causing this / what a fix might look like?

System Information

• Arch Linux on Kernel 6.14.2
• Latest Hyprland (0.48.0 built from the AUR hyprland-git)
• MPD 0.24.3
• Latest Vermilion (Commit de3f343 built with pnpm build:linux)

Footnotes

1. I presume it's something to do with the IPC, though I've never worked with electron before, so I'm not sure. ↩

[vaxerski]

it's likely chromium itself as we dont lazy load the list, if you have 2000 results we will ask chromium to create 2000 not-dead-simple divs

[Siri-chan]

Yeah, that seems about right
Just rendering song.title in plain(ish) text is nearly instant.

The next question is how to solve it. The options I see are to either:

• Make SongEntry less heavy of a component
• Limit the amount of songs actually rendered during the #each and doing some on-demand rendering.

The second option seems significantly harder but would probably be a better long-term solution.

[vaxerski]

second is the only real option