In 9969b01c5f we stopped updating the sublist whenever we felt like it, which indirectly froze message previews for room tiles (badges, unread state, etc were unaffected because that is managed by a different store). To fix this, we simply have to listen for changes and perform an update.
In 7b97c3032b we reduced the RoomList updates to just added/removed sublists, but didn't consider that we might also have to handle lengths of those sublists changing enough for us to fix the sticky headers.
Any time we though that the room list had to re-render we were dynamically creating a new addRoomFn, which would signal to the sublist that it needed to re-render.
The only reason we wrap the function from the aesthetics is to provide theoretical tiling/multiaccount support through use of different dispatchers, however considering that's not a reality yet we can just use a default dispatcher when none is supplied.
This cuts the render time in half (from ~448ms to ~200ms on my account) per received event, as we're no longer re-mounting the entire room list and instead just the section(s) we care about.
We were taking 0.2ms to handle the registration of a timer per event during startup, even before the app is visible to the user. These timers would be short-circuited too, leading to a bunch of wasted time.
0.2ms isn't a lot of time, but multiplied by thousands of events at startup it's pretty significant.
On my account this reduces the full page spinner time from ~50 seconds to just over 20 seconds.
This means we're abusing the AsyncStoreWithClient to get access to a lifecycle, but overall that seems like a minor crime compared to the time spend abusing the store's state as a map.
With thousands of rooms shown, we can save on average 743ms per preview. The new preview time is 0.12ms on average.
Fixes https://github.com/vector-im/riot-web/issues/14694
Instead of spending 10-1000ms in a function iterating over a whole lot of room events, we can use our cached state from the Notification State Store.
This commit sets up a structure that could be applied to communities in the TagPanel too, as that could probably use a similar optimization.
This reduces the updateStatusIndicator() time to just 4ms on average.
Changing the property on every render of the left panel (which is basically all the time) is super bad on the GPU and for our CPU. We should only do that when something changes.
Fixes https://github.com/vector-im/riot-web/issues/14475
Background: Sticky rooms are actually a pair of lies to the underlying algorithm as a combination of REMOVE_ROOM/NEW_ROOM calls so they don't get considered as needing to be sorted. When a room is added under the importance algorithm, it is expected that the category it is being added to will be re-sorted to account for the change, however we weren't doing that since we optimized the NewRoom path to be a splice operation.
