Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: use a ring buffer for the RoomListService cache #2246

Merged
merged 1 commit into from
Jul 11, 2023

Conversation

bnjbvr
Copy link
Member

@bnjbvr bnjbvr commented Jul 10, 2023

This will limit the memory used by the cache entries (while it was unbounded before). It's now possible to do this, since we have the latest_room_event handy for all the rooms; using the unbounded cache before was papering over the lack of that feature.

We can bikeshed on the number of entries in this cache. It has to be small enough to not blow up memory (and keep the linear search over room id fast, but it's secondary), and high enough that we don't hit the full timeline re-build path that often.

Address a bullet point in #1911.

@bnjbvr bnjbvr requested a review from a team as a code owner July 10, 2023 10:16
@bnjbvr bnjbvr requested review from jplatte and removed request for a team July 10, 2023 10:16
Copy link
Contributor

@poljar poljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, lets just consider bumping the cache size.

/// This number should be high enough so that navigating to a room
/// previously visited is almost instant, but also not too high so as to
/// avoid exhausting memory.
const ROOM_OBJECT_CACHE_SIZE: usize = 16;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to quite low, no? Some bigger tablets or desktop clients might fit that many rooms into the view.

How about ~100? Or 128 if you want it to remain a power of 2.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ivan suggested 20. I don't think it's a big issue to have a lot (the linear search may take longer, but it's nothing in the grand scheme of things), so I can use 128 (:nerd_face:) indeedy.

This will limit the memory used by the cache entries (while it was unbounded before). It's now possible to do this,
since we have the `latest_room_event` handy for all the rooms; using the unbounded cache before was papering over
the lack of that feature.

We can bikeshed on the number of entries in this cache. It has to be small enough to not blow up memory (and keep
the linear search over room id fast, but it's secondary), and high enough that we don't hit the full timeline
re-build path that often.
@bnjbvr bnjbvr force-pushed the ring-buffer-room-cache branch from d08cf70 to 8c83d03 Compare July 10, 2023 13:11
@bnjbvr bnjbvr enabled auto-merge (rebase) July 10, 2023 13:12
@bnjbvr bnjbvr disabled auto-merge July 11, 2023 08:56
@bnjbvr bnjbvr merged commit 9985a63 into matrix-org:main Jul 11, 2023
@bnjbvr bnjbvr deleted the ring-buffer-room-cache branch July 11, 2023 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants