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

Various smaller sliding sync fixes #1372

Merged
merged 11 commits into from Jan 24, 2023
Merged

Various smaller sliding sync fixes #1372

merged 11 commits into from Jan 24, 2023

Conversation

gnunicorn
Copy link
Contributor

@gnunicorn gnunicorn commented Jan 18, 2023

Various sliding sync fixes, providing tests where possible. ref #1359

  • more tracing around unfreeze code for better performance tracking
  • when recovering from cold or going live the first time, we used to fire a bunch of Empty-Insert events for every room in the total count. With this change, we are building the new list once and set it instead, leading to a much more feasible single Replace event being triggered
  • the view generators would only update upon the next loop iteration following the current cycle and they would update regardless of whether they actually succeeded, leading to two annoying bugs: live state only being set at the beginning of the next cycle and growing sync some times skipping beats. This changes the code to do a post-processing of the view-generator code after we've received the new update - based on the data of the update. Leading to one request less before live being triggered and fixing beat-skipping.
  • selective caching (part 1): we were caching the entire object at once, which meant that if you loaded a lot of rooms, deserializing that would take quite some times (we've seen 800ms being spent on that). The code was refactored to store room data alongside the view it belongs to allowing the API to select the views (by adding them before built) that are even attempted to look up. For me that drops the unfreezing time from 150ms to 30ms for a 14item selective view (ignoring a full-growing-sync-view).
  • Cancel stoppable spawn on drop, add helper fn subscribe_and_add_timeline_listener #1361 allows us to cancel the spawn of the sync loop - but that means we now might also miss updates sent by the server as any .await might get interrupted and thus processing of the results could fail. We can see in the logs that this happening and might cause gaps in the room list even. This has been fixed by switching to an AtomicBool to inform the inner loop to stop after every iteration rather than cancelling the actual JoinHandle.
  • properly reset the timeline if the server tells us to (via limited flag) fixes the problem of gappy timelines when the room ran out of scope and came back in.
  • checker whether a given room id is in the visible range and an optional flag to ask the view to trigger updates for rooms that are in the view regardless of whether their positions was updated in the view.

@gnunicorn gnunicorn requested a review from a team January 18, 2023 11:54
@gnunicorn gnunicorn force-pushed the ben-fixing-various-1359 branch 2 times, most recently from 7232f65 to c267be8 Compare January 18, 2023 14:52
crates/matrix-sdk/src/sliding_sync.rs Outdated Show resolved Hide resolved
crates/matrix-sdk/src/sliding_sync.rs Outdated Show resolved Hide resolved
Before we'd push one empty entry at a time, which lead to a lot of vecdiff updates pushed. With this
we now only push one  event after the entire operation set has been applied on the fresh
or cold view.
@gnunicorn gnunicorn requested a review from a team January 18, 2023 22:43
@gnunicorn gnunicorn force-pushed the ben-fixing-various-1359 branch 3 times, most recently from 27d33f5 to e84341f Compare January 23, 2023 16:32
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.

Look good, left a couple of nits.

@@ -167,154 +177,239 @@ mod tests {
// index-based views don't support removing views. Leaving this test for an API
// update later.
//
// #[tokio::test(flavor = "multi_thread", worker_threads = 4)]
Copy link
Contributor

Choose a reason for hiding this comment

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

What's up with this test? It seems to be the same one as further bellow with the same name, which is ignored instead of commented out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

there is no commented-out one further below anymore. I removed the comment and instead opted for ignoring it for better visibility. This is probably a mixup in the history... the final result only has the ignored one.

@gnunicorn gnunicorn merged commit 24ac5b9 into main Jan 24, 2023
@gnunicorn gnunicorn deleted the ben-fixing-various-1359 branch January 24, 2023 10:30
@@ -491,10 +505,8 @@ impl SlidingSyncView {
) -> Arc<StoppableSpawn> {
let mut room_list = self.inner.rooms_list.signal_vec_cloned().to_stream();
Arc::new(StoppableSpawn::with_handle(RUNTIME.spawn(async move {
loop {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

grrr... leftover from a bad refactor that wasn't fully reverted: we still need this loop { here ...caused stupid bug...

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

3 participants