Timeline rendering optimizations #6143
Conversation
An accidental variable shadowing was preventing setting watcher callbacks from being fired. Signed-off-by: Robin Townsend <robin@robin.town>
Signed-off-by: Robin Townsend <robin@robin.town>
Signed-off-by: Robin Townsend <robin@robin.town>
Signed-off-by: Robin Townsend <robin@robin.town>
Signed-off-by: Robin Townsend <robin@robin.town>
Signed-off-by: Robin Townsend <robin@robin.town>
Signed-off-by: Robin Townsend <robin@robin.town>
Signed-off-by: Robin Townsend <robin@robin.town>
robintown
changed the title
There was a problem hiding this comment.
Thank you for working on this!
That makes a lot of sense and it seems that you managed to get some quite significant improvements that will increase the overall smoothness of the application
I did not realise that the SettingsStore calls were that expensive and caching the values looks like a good addition to what we have.
I am wondering whether that caching could exist within the SettingsStore directly so that the entire application can benefit from those performance improvement? But I am not overly familiar with the difficulty this would entail
The changes in TextForEvent seem quite reasonable. The only thing that I am unsure about is that now the function name does not match with the return type of those function.
I can imagine that we could
- Rename the functions
- Migrate to TypeScript and have more explicit naming
To illustrate what I'm saying, before:
function textForMemberEvent(ev: MatrixEvent): string | nullAfter:
function textForMemberEvent(ev: MatrixEvent): () => string | null
|
@gsouquet Yeah, there are very probably some general SettingsStore optimizations that would be good to look into in the future, but generally, caching and watching individual settings as needed seems to be the way to go, since that then enables components to dynamically update whenever those setting values happen to change (which is particularly useful for the timeline, as it can be open in the background while you flip switches in the settings menu). Michael pointed out to me the other day that there is a Adding types to TextForEvent is a great idea, I'll get to that tomorrow evening :) |
Signed-off-by: Robin Townsend <robin@robin.town>
I managed to improve timeline rendering performance significantly by caching a few frequently hit settings values in RoomContext, and introducing a faster function to determine whether events have text to display, rather than abusing
textForEvent.These changes were targeted at improving MELS performance, since having a large number of member events in one place is one of the easiest ways to get noticeable lag, but none of the slowdowns I saw ended up being specific to MELS.
Before (scrolling through #keepassxc:matrix.org):
After (scrolling through #keepassxc:matrix.org):
Closes element-hq/element-web#17537, because I was specifically targeting the slowdowns highlighted in that issue.
Closes element-hq/element-web#10371, because this changes the operations referred to in that issue to no longer be expensive.
I also think this should be a big enough improvement to say:
Closes element-hq/element-web#11963.
Closes element-hq/element-web#9061.
Closes element-hq/element-web#7015.
…though I would like confirmation on those, since in my testing even though I visited the same rooms with hundreds of grouped member events, I couldn't really reproduce the claims of ~1 minute hangs. I think I've fixed what is likely to have caused those, though.