Speed up time-to-first-enqueue

[joshkunz]

Right now, we performance test ashuffle startup (time to first enqueue) at <750ms for a 20k track library. This is still surprisingly slow. We should try and improve this.

I think a reasonable target would be <200ms startup with a 100k track library. That should be fast enough that the user never notices ashuffle startup.

[hindumagic]

Hi, just an idea..
I don't know how ashuffle specifically works, but I assume that it performs a listallinfo on startup for every execution. One approach would be to save down that info and only do a check on startup if there is new info (like total number of tracks changed or if mpd has a mechanism for this).

[joshkunz]

That's not a bad idea. It could probably key off of the db_update field of the stats command. A big question for me, is how it would interact with filters. I'm not totally sure of the timing breakdown at startup, but it seems like we'd probably want to cache the filtered song set (the loaded "shuffle chain") which would depend on the filters passed at startup.