When all room members are loaded, we do not need an incremental member update. We know that parsing the /members response will only lead to more ambiguous names, not less. And because /members returns the complete list, we can directly use that list as the disambiguation map.
This improves the performance in my emulator from 56s to 9s and on a less performant device from 11mins to 11s (Tested experimentally on Matrix HQ using log statements in element android. If I have time, I will write a proper benchmark tomorrow.
See also https://github.com/matrix-org/matrix-rust-sdk/pull/3184#issuecomment-1986170631 for a more detailed benchmark run.
---
* members: Simplify disambiguation logic
* members: Prevent api misuse for receive_members
* members: Benchmark receive_all_members performance
* sdk: remove unused import
* sdk-base: rename `ApiMisuse` error to `InvalidReceiveMembersParameters`
* benchmarks: extract the member loading benchmark to `room_bench.rs`
* benchmarks: remove wiremock
* sdk-base: fix format
* sdk-base: try fixing tests
* benchmark: Provide some data to the store so the search and disambiguation happen
* benchmark: fix clippy
* benchmark: use a constant for `MEMBERS_IN_ROOM`
* sdk(style): reduce indent in `receive_all_members`
---------
Co-authored-by: Jorge Martín <jorgem@element.io>
Co-authored-by: Benjamin Bouvier <public@benj.me>
This does two things:
- raise the timeout value for the `/members` queries, because they can super slow in Synapse because of nasal demons,
- and aggregate all the fields of `RoomMember` early, so users don't have to call getters to read each field.
---
* room_members: Export plain old data for room members to avoid FFI calls
Signed-off-by: Timo Kösters <timo@koesters.xyz>
* room_member: Respond to review feedback
* room_member: Remove previous RoomMember struct
* ffi: rename ExportedRoomMember to RoomMember
---------
Signed-off-by: Timo Kösters <timo@koesters.xyz>
Co-authored-by: Benjamin Bouvier <public@benj.me>
The workflow inside `Client::receive_sync_response` is a little
bit fragile. When `Client::handle_room_account_data` is called, it
modifies `RoomInfo`. The problem is that a current `RoomInfo` is being
computed before `handle_room_account_data` is called, and saved a
couple lines after, resulting in overwriting the modification made by
`handle_room_account_data`.
This patch ensures that the new `RoomInfo` is saved before
`handle_room_account_data` is called.
Now that `NotableTags` has replaced `RoomNotableTags` entirely, this
patch can rename `NotableTags` to `RoomNotableTags` as it's a better
name for it.
Note that this type is private to `matrix_sdk_base`, so it's fine to
rename it.
The Matrix specification uses the `m.favourite` orthography. Let's use
the same in our code. So `set_is_favorite` becomes `set_is_favourite`.
This patch updates this in various places for the sake of consistency.
The previous patch has introduced the new `NotableTags` type to replace
the `RoomNotableTags`. This patch removes the latter.
This patch keeps the `Room::set_is_favorite` and `::set_is_low_priority`
methods. However, this patch adds the `Room::is_favourite` and
`::is_low_priority` methods, with the consequence of entirely hiding the
notable tags type from the public API.
This patch is the first step to remove the [`RoomNotableTags`] API. The
idea is to compute the notable tags as a single 8-bit unsigned integer
(`u8`) and to store it inside `RoomInfo`. The benefits are numerous:
1. The type is smaller that `RoomNotableTags`,
2. It's part of `RoomInfo` so:
- We don't need an async API to fetch the tags from the store and to
compute the notable tags,
- It can be put in the store,
- The observable/subscribe mechanism is supported by `RoomInfo` behind
observable instead of introducing a new subscribe mechanism.
This patch implements `Room::direct_targets_length`. It avoids to call
`Room::is_direct` if and only if we don't care about the room's state
and we don't want an async call, and if we don't want to pay the cost of
`Room::direct_targets` which clones the `HashSet` as an alternative way
to get a similar information than `Room::is_direct`.
I think the reasoning behind using a RwLock for sync, and notably allowing multiple concurrent `.read()` lock taking was flawed: since there's no way
to identify which subpiece of the store we're reading and writing, there could be two concurrent requests to the write to the same thing at the same
time. To get rid of this possibility, this commit changes the lock to a single access only Mutex lock.
To update the avatar of a room, one has to look up in the state event.
That's the canonical way to do. For Sliding Sync, it means looking
inside the `required_state` field of the `v4::SlidingSyncRoom`. This
case already works and was tested.
However, a `v4::SlidingSyncRoom` comes with a direct `avatar` field.
It's another way to know the avatar URL of the room. This case was
handled and tested in `matrix_sdk::sliding_sync::SlidingSyncRoom`, but
it was never propagated into the proper sync mechanism. So when the
`avatar` field was set up, `matrix_sdk::sliding_sync::SlidingSyncRoom`
was holding this information, and the `avatar` wasn't defined in the
proper `Room`: `SlidingSyncRoom` has to look up inside the `Room` as
a fallback.
This patch is the first one to fix this “fallback” mechanism.
The `avatar` field of a `v4::SlidingSyncRoom` now triggers an update to
the new `RoomInfo::update_avatar` method (à la `update_name`), via
`process_room_properties`.
Makes AmbiguityChange easier to use, especially outside of SyncResponse,
where we might not have the m.room.member event.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This fixes an issue with the sliding sync processing where room account data are not processed when the associated room has no other changes.
---
* sliding_sync : fix room account data not being processed when there is no other changes in the room
* sliding_sync : properly handle room_account_data from extension
* sliding_sync : add test for processing rooms_account_data
* sliding_sync : fix formatting
* Apply suggestions from code review
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
Signed-off-by: ganfra <francois.ganard@gmail.com>
* sliding_sync : avoid cloning room account data events
Co-authored-by: Benjamin Bouvier <public@benj.me>
Signed-off-by: ganfra <francois.ganard@gmail.com>
---------
Signed-off-by: ganfra <francois.ganard@gmail.com>
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
Co-authored-by: Benjamin Bouvier <public@benj.me>
