Fix song select realm refresh performance #25838
Conversation
Realm will batch the updates. We don't want to do expensive operations per set when we don't need to.
The only case where this was checking is guaranteed by realm to only be called once.
peppy
added
the
next release
|
The invalidation logic changes are very difficult to follow. I'm still not sure whether behaviourally The test failures are not encouraging. Not sure if you want to look into them, or should I. |
Originally as far as I can tell it was only guarding in the realm callback, when the changeset is null. This is guaranteed by realm to only occur once, on initial event subscription. |
…unt and `LastSelected`" This reverts commit 25df426.
|
I've reverted one change for now in the interest of getting this in. Will revisit it as a separate PR. |
|
One test remains flaky, trying to figure out what's going on but have not repro'd locally yet. |
I think this is required because there is a higher chance of batched updates with the new structure (and less calls to `BeatmapSetsChanged` which causes re-selection).
No, I'm not sure what that means for this diff, since the rest of your answer is rather enigmatic, but there. Edit: It appears irrelevant now that I look at it again. With the latest changes I feel much more confident that |
|
Tests are failing because after beatmap removal the difficulty count under search bar does not update properly anymore. It shows stale counts from before the deletion. Previously the deletion of items from carousel would happen before summing up the difficulty counts, but now it happens after. So this is a regression from 8f5d21d specifically. |
|
Easy fix, luckily. Just recalculate after deletion (should have been there all along). If another test breaks I will not be a happy peppy. |
|
Appears to be fine now, but I want this to go through a CI run with master merged before merging just to make sure I don't get clowned by unexpected crosstalk between this and the filtering fix. |
Closes #25824
Each commit is basically standalone.
If any are seen as hard-to-merge or break test expectations, we can cherry-pick the good ones for now.
87b7699 takes things from <1 FPS to a substantially usable frame rate with occasional stutters.
The rest of the commits work to reduce the stutter down to <100ms.
Can be tested using test database