Room list performance is badly regressed on build 638

[ara4n]

Steps to reproduce

1. Install TF 638
2. Open app
3. See room list take 5-10s to actually appear
4. Later, search for a room
5. Have to wait 10s for the right room to show up - meanwhile all sorts of weird incorrect results flash up while it searches.

Outcome

What did you expect?

Instant room list filtering, even on big accounts like mine.

What happened instead?

10s to filter the room list, with loads of false results.

Your phone model

No response

Operating system version

No response

Application version

638

Homeserver

No response

Will you send logs?

Yes

[ara4n]

Build 638 doing it wrong: https://github.com/element-hq/element-x-ios-rageshakes/issues/1941
Build 637 doing it right: https://github.com/element-hq/element-x-ios-rageshakes/issues/1942

[bnjbvr]

For what it's worth, the SDK changelog (based on commit SHAs) is the following, which doesn't seem to include any performance-sensitive changes, or any change related to the room list itself:

52fa00e47 sdk: remove `Error::InconsistentState` as it was unused
17d18321f send queue: mark `ConcurrentRequestFailed` as recoverable
374da7674 crypto: Remove assert_matches2 from regular dependencies
38a18c3c8 feat(ffi): add Element specific well known struct and a way to deserialize it from external clients
70fddc0e1 feat(ffi): expose method for reading the server name part of the current user's identifier.
84796ab32 feat(ffi): expose method for sending generic GET requests through the SDK's inner HTTP client.
6464d2181 crypto: Storage changes for keeping sender data with InboundGroupSessions (#3556)
cb4c57523 Reshare Megolm session after the other party unwedges (#3604)

[ara4n]

i may also be seeing weirdness in 636 (on macOS at least). although 637 on iOS seems ok :/

update - 637 on iOS is also intermittently being incredibly slow

[manuroe]

Probably related to is_encrypted field we are going to remove

[bnjbvr]

Fixed by matrix-org/matrix-rust-sdk#3655

[ara4n]

hmm. has this hit EXI Nightly yet? should the bug be closed once it hits the app and is confirmed closed, rather than at the SDK level? I'm still seeing sluggish roomlist filtering on bad connectivity on EXI 642 (i.e. with local list sorting), but from a QA perspective I don't know if this is a new bug or not. Reopening for now...

[ara4n]

confirmed fixed in 644