Conversation
91c07a7 to
698c0d5
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #6877 +/- ##
==========================================
- Coverage 90.30% 90.27% -0.04%
==========================================
Files 414 415 +1
Lines 120232 120616 +384
Branches 120232 120616 +384
==========================================
+ Hits 108576 108882 +306
- Misses 7579 7620 +41
- Partials 4077 4114 +37 ☔ View full report in Codecov by Harness. |
Merging this PR will degrade performance by 50.2%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ | Restore session [memory store] |
236.2 ms | 474.3 ms | -50.2% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing alexookah:specific-events-cache (89efd49) with main (7604d4f)
6ce3fc2 to
6eb7db7
Compare
|
@Hywan |
32b5377 to
403542f
Compare
|
Hello @Hywan |
Move the loading of events with their reactions and edits out of PinnedEventsCache into a function that other caches can use, and skip an event that is both requested and a relation of another one. No behaviour change for pinned events.
The state of a cache for a caller-supplied set of event IDs: the ids, a linked chunk holding the events and their relations, and the handling of sync events related to them (dedup against loaded relations, append the rest, apply redactions). It lives in the event cache's state map under a per-instance selector, so several such caches can coexist for one room. In-memory only: nothing is written to the store.
The handle over that state: create it for a set of ids, load the events with their reactions and edits through the shared loader, read or subscribe to them, and replace the set with set_event_ids(), which reloads when it changed and keeps the previous set if nothing could be loaded. Loading never holds the state lock, since it goes through the event cache, which needs it too.
…yption RoomEventCache creates the caches on demand and forwards them the sync timeline filtered to their events, EventCache exposes them, and the redecryptor resolves their in-memory UTDs, like for the other caches that live only in memory. The initial load happens once the room caches' guard is released.
Loading a set with its relations in chronological order and without duplicates, skipping ids that can't be loaded and failing when none can, sync updates reaching the cache (reactions, edits, redactions of the events and of their relations) while unrelated events don't, set_event_ids being a no-op for the same set, reloading when it grows or shrinks and keeping the previous set on failure, and the not-subscribed error.
403542f to
a5f5499
Compare
…into specific-events-cache # Conflicts: # crates/matrix-sdk/src/event_cache/caches/mod.rs # crates/matrix-sdk/src/event_cache/caches/pinned_events/mod.rs
|
Hi @Hywan, I brought this up to date with main and added a few tests. |
First event-cache step for #6876.
SpecificEventsCacheis the pinned-events approach with the id list supplied by the caller instead of coming fromm.room.pinned_events.aggregate_timeline_for_pinned_eventswith the cache's current ids, so reactions, edits and redactions of what it holds reach itset_event_ids(): diffs the set and reloads if it changed; a set that can't be loaded at all is an error and the previous set is keptSix commits: the loader refactor, the state and how it follows sync, the cache handle, the wiring into the room caches, the tests, and the weak handles.
A store clear leaves these caches alone on purpose: nothing of theirs lives in the store, and sync keeps them current.
No timeline or FFI yet.