Switching spaces has significant lag

[NathanC]

Describe the bug

When switching between spaces on the left, there is very significant lag before the panel on the right updates to show the correct rooms. This lag is sometimes 1-2 seconds, but often 5-10 seconds.

To Reproduce Steps to reproduce the behavior:

1. Go to any space
2. Click on any other space, top level or nested
3. Note the delay
4. Repeat steps, going between various spaces, and note the variation in delay

Expected behavior Snappy transition to view of dedencent rooms when navigating to a new space.

Smartphone (please complete the following information):

• DEVICE Pixel 5
• OS: Android 13

Additional context

• App version: 1.5.2.sc61 (with some suffixes that seem identifying, let me know if you need those)
• Store: Google Play
• Homeserver: Willing to share privately if needed

Upstream relevance

• Does this issue exist in Element Android? Yes, delay between spaces switch is quite noticeable
• If this issue exists in Element Android, please also link the corresponding bug report (create a new one if it doesn't exist yet). There's 2k open issues upstream-- if you don't mind, I'd like to see if this is a common problem people have with SchildiChat before opening an upstream issue, or if this is specific on my end/due to my homeserver somehow

Context

Happy to perform additional debugging, but not quite sure what to look for. I have turned off dev settings to see if that was causing this issue, and it doesn't seem to be.

Are rooms within spaces not cached? It seems like either significant data is being fetched every time, or that there is a UI bug with switching spaces.

I love a lot of things about the SchildiChat app, and any help with this issue is appreciated-- it's causing a lot of usability issues, because of how heavily I use spaces. I just tried FluffyChat and space transitions are very snappy, but Fluffy is missing a lot of features from Schildi currently-- still, it implies the issue isn't with my homeserver, or at least that there's a caching pattern that could work well here.

I have 5 top level spaces, but my Discord space has quite a fair number of nested spaces underneath it (I bridged with a fairly large server), probably about 15 spaces nested total, either at 1 or 2 levels. I'm wondering if it has too many spaces, and so spaces are constantly cycling in and out of a cache? I know spaces are a fairly new feature.

[SpiritCroc]

There's a huge overhead on the structural side of Element when it comes to switching spaces. I'm not planning on touching that. We do have "swipe to switch spaces" in labs though, which adds a bottom bar for switching spaces, at least if you only care about switching root spaces. This one currently avoids the overhead from Element's switching spaces method, and could thus be faster, but may also have some bugs currently.

[NathanC]

I tried the "swipe to switch spaces" feature on a hunch that it would help, and the behavior is definitely different-- sometimes it loads quickly, but sometimes there's a long load as well, seems unpredictable.

And that's understandable that you don't want to touch it, seems like an unfortunate but reasonable constraint of being a fork. I'll file an upstream issue.

Would you mind giving me a tl;dr; on your understanding of why there's so much structural overhead upstream with this, so I can file a better issue? Do you know if they cache rooms within spaces?

(by the way, I got the Beeper android-sms Bridge up and running and it works great! Thanks for the link to that in SchildiChat desktop issue)

[SpiritCroc]

And that's understandable that you don't want to touch it, seems like an unfortunate but reasonable constraint of being a fork. I'll file an upstream issue.

This has been complained about several times before, e.g. https://github.com/vector-im/element-android/issues/3830

Would you mind giving me a tl;dr; on your understanding of why there's so much structural overhead upstream with this, so I can file a better issue? Do you know if they cache rooms within spaces?

The two issues I'm aware of (but don't quote me on it, has been a while since I checked it):

• Element has the space filter in some app-wide data structure, which may cause issues with locking, not sure
• RoomSummary updates are inefficient. Whenever one room summary changes in the database, the whole list needs to be copied for every listener in the app, if I remember correctly. (and spaces are just rooms, so same applies to space lists) - but this one might not be directly related here, but for other slowness issues, like marking chats as (un)read

(by the way, I got the Beeper android-sms Bridge up and running and it works great! Thanks for the link to that in SchildiChat desktop issue)

Cool :+1:

[NathanC]

Ah, I searched upstream before posting this, but I missed that issue-- so many issues to dig though, though I probably just used poor search terms.

The last comment on the issue you linked says

I think sync might actually be the reason. On my device I have these logs on every sync:

2022-07-14T14:29:35*770GMT+00:00Z 27693 V/ /Tag: ## SPACES: Finish checking room hierarchy in 1254 ms

The performance is much better if I go in airplane mode. I looked at the code a bit and my theory is that the space hierarchy calculation gets a lot slower the more users you have lazy loaded. That would explain why it's fast after an initial sync.

Without knowing more about the Arch, it sounds like it blocks on re-sync, instead of displaying its cache and lazy loading changes after a sync. A loading icon on rooms after switching spaces could work.

I don't quite get why sync is needed here though? Doesn't the client listen for all changes, meaning the state is always synced to the latest after initial sync? What exactly is it syncing?

I would assume it does the initial sync and builds a tree of spaces with rooms as the leaf nodes, with each room being a reference to a room object with room history. If that was the case, showing a space is just a search on that branch of the tree, showing the rooms and their latest update in the right panel. Is the Arch generally like that, or totally different?

(if you want to close this issue and redirect me to a matrix channel to ask someone else this, that's totally fine!)

[NathanC]

Though from your comment above, it sounds more like spaces are tacked on as a filter to the existing d as ta structure, as opposed to being their own tree.

[SpiritCroc]

I don't think sync is the issue. I'm not aware of any network requests that this relies on. You can test by turning your device offline though, if it's faster then, there may be some weird network thing hidden.

But of course, I haven't really looked into this issue yet, so I don't know.

[NathanC]

I don't think sync is the issue. I'm not aware of any network requests that this relies on. You can test by turning your device offline though, if it's faster then, there may be some weird network thing hidden.

I just tested in airplane mode, and space switches are almost instantaneous. It's a massive speed difference-- occasionally it slows a full screen spinner for half a sec (probably could be a slight UX improvement there but w/e) before showing the space, but often it's instant.

I'm tempted to try and make an upstream change, but I'm a bit daunted by that repo (2k issues is.. a lot). I've done React Native before but never Kotlin, so I'd have to learn the dev process. Any tips for working with/contributing to the upstream codebase, from your experience?

[SpiritCroc]

I just tested in airplane mode, and space switches are almost instantaneous. It's a massive speed difference-- occasionally it slows a full screen spinner for half a sec (probably could be a slight UX improvement there but w/e) before showing the space, but often it's instant.

Hm, ok, then it seems worth investigating (but I still don't have it on my priority list right now).

I'm tempted to try and make an upstream change, but I'm a bit daunted by that repo (2k issues is.. a lot). I've done React Native before but never Kotlin, so I'd have to learn the dev process. Any tips for working with/contributing to the upstream codebase, from your experience?

• For android development, you will want to use android-studio as IDE.
• Most important directories are matrix-sdk-android, where the underlying Matrix logic goes, and vector, where the app UI logic goes. You're probably mostly interested in the vector module for this one, at least as starting point.
• If you open a PR to upstream, they tend to be slow in reviewing it, so if you want to have your fix quickly included in SchildiChat, you might want to open another PR here (even though depending on the change, I might prefer to wait for upstream review / code inclusion, especially if it would cause lots of merge conflicts otherwise)

[github-actions[bot]]

This issue is stale because it has been open 150 days with no activity. Remove stale label or comment or this will be closed in 14 days.