UI performance regression since v1.3.0

[codl]

Since v1.3.0 the web ui is very slow on chrome for android, on my oneplus 3t it often takes over five seconds to expand a toot or switch to a different tab

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[kyzh]

I have the same story here on oneplus1, firefox.
I'm also having more firefox crashes, which were non existent before.
Do @ me here or in mastodon.social if you need more data or help to test a PR

[nolanlawson]

I'm not seeing anywhere near 5 seconds for expanding a toot in Chrome 57 on a Nexus 5X on Mastodon V1.3.2 (more like 1-2 seconds) but I am interested to look into this.

[nolanlawson]

Well I tested this on a Nexus 5 Running Chrome 37, on toot.cafe (currently Mastodon 1.3.2). The first one is switching from the "*" menu to the notifications, and the second is expanding a toot.

A bit impenetrable since most of it is framework code (to me anyway; I'm not experienced with React), but I do recognize some expensive layout/style recalcs (the purple part). Unless it was something that changed in Mastodon's CSS or DOM structure, it looks instead like something may have changed in the React part. I'd have to have a v1.2.2 server to compare against, though.

[codl]

if it helps I recorded a chrome dev tools profile of chrome freezing for 35 seconds (!) while switching to the home tl

[Gargron]

I believe v1.3 is where we added a thing that hides some columns instead of unmounting them, when switching between them, which makes them keep their scroll position without a repaint (which was source of a ~100ms lag prior). Could this be it? Storing lots of hidden elements in the DOM instead of unmounting backfiring/crashing on phones?

[arielsbecker]

Not sure if it helps, but I can confirm this behavior in SeaMonkey 2.4x. In mstdn it eats lots of CPU instead, but the UI is fluent AFAIK.

[nolanlawson]

@codl According to that trace you posted, the browser was blocked on the network for 35 seconds, not the UI:

In particular it was waiting on two requests for /card and /context. May be a server-side problem with chitter.xyz.

[Gargron]

I just realized why the UI would start eating CPU so much. It's obvious in hindsight. Even if the part of DOM in question is invisible, if it's a mounted React component, it will get updated. Having the local timeline, public timeline, etc etc be secretly mounted means they're all getting updated at the same time. This might be reason to revert #2271? Perhaps there is an alternative way to avoid the scroll layout lag?

[nolanlawson]

Is there a way to tell React to de-prioritize those hidden components and then update them using requestIdleCallback? Skimmed the React docs, but it seems the answer is no. In that case maybe it is worth it to unmount for the memory/CPU savings even if it's a bit more expensive to switch views.

[fceschmidt]

I am noticing this issue too. If I look at the federated TL on hex.bz the CPU usage goes up to 90-100%, and stays there until I close the tab. It's really making my 8 year old notebook unresponsive.

[nolanlawson]

Can you post a trace by any chance?