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: Client-side sorting for the room list #3068

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

Hywan
Copy link
Member

@Hywan Hywan commented Jan 29, 2024

This PR is a work-in-progress. The idea is to provide client-side sorting for the rooms.


Blocked by:

`Store::get_rooms` worked as follows: For each room ID, call

* Take the read lock for `rooms`,
* For each entry in `rooms`, take the room ID (the key), then call `Store::get_room`, which…
* Take the read lock for `rooms`,
* Based on the room ID (the key), read the room (the value) from `rooms`.

So calling `get_rooms` calls `get_room` for each room, which takes the lock every time.

This patch modifies that by fetching the values (the rooms) directly
from `rooms`, without calling `get_room`.

In my benchmark, it took 1.2ms to read 10'000 rooms. Now it takes 542µs.
Performance time has improved by -55.8%.
This patch updates `Store::rooms` from a
`Arc<StdRwLock<BTreeMap<OwnedRoomId, Room>>>` to a
`Arc<StdRwLock<Rooms>>` where `Rooms` is a new type that mimics a
`BTreeMap` but that is observable. It uses an `ObservableVector`
for saving us the costs of writing a new `ObservableMap` type in
`eyeball-im`. It would have too much implications that are clearly
not necessary. The major one being that an `ObservableMap` must emit
`MapDiff`, but we expect `VectorDiff` everywhere in the SDK where rooms
are observable. It would break too many API and too many projects.

The benchmark is coming, but here are the results (for 10'000 rooms, extreme case):

* `get_rooms` and `get_rooms_filtered` are twice faster (in practise, it
  means 650µs is saved per call),
* `get_room` and `get_or_create_room` are 10% slower (in practise, it
  means 8-10ns is lost per call).

Overall, I believe these results are acceptable, and even an improvement
for the first one.
This patch rewrites `Rooms` to a generic `ObservableMap` struct. It also
adds documentation and tests for this type.
This patch basically implements `ObservableMap::stream` which returns a
batched stream of the values.
This patch renames `Store::get_rooms`, `::get_rooms_filtered` and
`::get_room` to respectively `::rooms`, `::rooms_filtered` and `::room`.
This `get_` prefix isn't really Rust idiomatic.
This patch implements a new `Store::rooms_stream` method that forwards
the result of `ObservableMap::stream`.
This patch renames `Client::get_rooms`, `::get_rooms_filtered` and
`::get_room` to respectively `::rooms`, `::rooms_filtered` and `::room`.
This `get_` prefix isn't really Rust idiomatic.
…tion` is enabled.

Running `cargo test -p matrix-sdk-base --features e2e-encryption`
makes the code to fail to compile because `crate::latest_event` isn't
defined. And indeed, it must be defined if `experimental-sliding-sync`
is enabled, but also if `e2e-encryption` is enabled.
This patch implements `Client::rooms_stream`, which forwards the result
of the recently added `Store::rooms_stream` method.
This patch implements `Client::rooms_stream` by forwarding the
result of `matrix_sdk_base::Client::rooms_stream`, and mapping the
`matrix_sdk_base::Room` to `matrix_sdk::Room`.
/// The (key, position) tuples.
mapping: HashMap<K, usize>,

/// The (position, value) tuples.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/// The (position, value) tuples.
/// The values.

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.

None yet

2 participants