CPU churn on incremental sync after load

[richvdh]

@dbkr says: 'I looked at the CPU churn on an incremental sync after load recently, and a lot of it was caused by the Constant Time Dispatcher now dispatching a separate Refresh event for every roomstate.member event, causing each RoomTile to refresh separately (if power levels change in a room, a roomstate.member event will be emitted for every member in the room).'

[ara4n]

see also https://github.com/vector-im/riot-web/issues/3755

[dbkr]

Actually it looks like it just all churning through timeline events because even limited to however many you get per room in a limited sync, you still get a shedload if you're in a lot of rooms and every single one causes a timeline event.

Basically we want to just do one bulk UI update once the incremental sync is processed so it's not a dissimilar problem although a more general one

I think the options are basically

1. make the js batch events
2. go through as many places as we can and go if (sdk.state == 'prepared') return and sdk.on('state', function(s) { if (s == 'SYNCING') refresh(); }
3. put a layer of indirection between components and the sdk

[dbkr]

Actually I think almost all of it is RoomList's onRoomTimeline

[tidux]

Perspective on how slow riot-web is: I see the Riot tab using 30-100% of a CPU core under Firefox 55beta on an i7-6700HQ. A 6700HQ with an NVMe SSD should not be perceptibly slowed by one Firefox tab. This is with about 30 rooms.

[lukebarnard1]

make the js batch events

Alternatively we (optionally) don't emit events for an initial sync or a sync loaded from cache. Following either of those, we emit events as dictated by what arrives in the incremental /sync.

[MadLittleMods]

Closing as the app has evolved since 2017 (5 years ago) and a new investigation will probably be necessary to make meaningful progress on the current hot spots.

[turt2live]

This is still very much an issue.