react-native: App performance is degraded when react native version updated to 0.71.2 from 0.68.0

This seems like it could be related to #36296 and #35778. In our case, in a repo where the only change was switching react-native from 0.69.7 to 0.70.7, startup time almost doubled, we experienced double average memory consumption and a huge spike in ‘slow renders’ as tracked by our remote logging tool, and various misc complaints from users about freezing / lag.

@cortinico #35778 Contains some reproductions and video demos. I understand this is a vague and complex issue, so thank you for following this thread, and if there is anything you need in terms of extra info or more reproductions, please let me know and I’ll get on it. This is probably the number 1 issue facing our RN app as it prevents us upgrading, so eager to help in whatever way possible 😄

Hey all, Nicola here from the React Native core team.

To bring clarity to this issue (which is similar to #37335 and #36296): we’re currently investigating this and other regression that gets reported by users on the repository.

As you all can see by the number of open issue, we can’t fix all the bugs. Therefore we try to prioritize the one that are affecting the biggest group of users. This is one of them as it seems a number of users have been reporting a similar issue.

I don’t have an ETA at this stage, but I’m happy to update as soon as we have more concrete results at hand.

In the meantime, we’re more than happy to collaborate with member of the community in investigating this issue and try to understand where the regression comes from.

@tj-mc @cortinico not a reproduction but possibly valuable information, or might be a separate issue

We use react-native-performance v4 from @oblador to measure onstart performance. I added some supported marks and reported them.

We released an upgrade from 0.69 to 0.70 at the start of february and have seen the amount of time between runJsBundleStart and runJsBundleEnd on iOS explode:

Median:

90th Percentile:

We use Hermes across Android/iOS, could this be a performance regression in Hermes?

Going to keep digging what else might have caused this in that release but wanted to just chime in, oddly I don’t see any reduction on Android.

This graph shows our memory usage after the rollout, which helped us initially identify the problem. In our case, we only saw an increase in iOS.

These are two identical builds of our app, except the left is RN 0.69.7, and right is RN 0.70.7.

0.70.7 experiences:

• Drastically increased startup time
• Almost double memory usage (only on iOS in our case)
• Animation / navigation freezing + stuttering
• JS engine freezes completely
• All of the above are twice as bad in Lower power mode on iOS

<video src="https://user-images.githubusercontent.com/46665295/231018682-6c1719b0-7983-4a0e-9a29-61743899c443.mp4" width="350"/>

Please avoid off-topic discussion not related to fixing the bug. Many of us are watching this issues with alerts on and it creates noise.

Hey everyone - a quick update on this performance issue: we’ve just released:

• https://github.com/facebook/react-native/releases/tag/v0.71.7
• https://github.com/facebook/react-native/releases/tag/v0.70.9

Both contain a fix for how we build Hermes’ artifacts that should help address this problem. Please upgrade to those versions and let us know if they help!

One clarification is I used jsc for the 0.71.3 video I added to https://github.com/facebook/react-native/issues/36296:

0.68.2 (snappy): https://www.loom.com/share/d0f9dac183f849e2ac6c6909b26a24c3 0.71.3 (significant lag on the learn tab): https://www.loom.com/share/2b73dae94d324b999d7ed31832565779

Hermes for 0.71.3 is unfortunately even worse. So there may be two separate issues between hermes accidentally being compiled without optimizations and whatever overall architecture changes have also impacted jsc.

@tj-mc Hi there! We are looking into the issue, trying to understand what’s going on. To rule out problems with hermes, could you make these tests for us?

In version 0.71.x

• Try to install the pods with PRODUCTION=1 bundle exec pod install. This should force React Native to download a version of Hermes for production that could contain some optimization. This can help us to rule out that we are building the wrong version of Hermes for Debug.

i have same issue its very slow and i have a lot of frames drops after update from 0.69.2 to 0.71.3

Hi @kelset, We can see the performance improvement related to JS thread processes. But there is still issue with react-native/navigation, we can see lag/delay while navigating in android (while comparing with react-native 0.68.0, “@react-navigation/drawer”: “^6.4.1”, “@react-navigation/native”: “^6.0.10”, “@react-navigation/native-stack”: “^6.6.1”, with latest versions of all).

Hey folks - we released a couple more RCs for 0.72 and in them there are a few commits which should help address the perf regression: can you try RC5 and let us know if it helps?

@kelset seems like someone opened a new issue #37335 for 0.71.7

I have the same issue when using debug mode. But when I tried release mode it run smoothly. It’s very slow in debug mode. I’m using flipper. // 0.71.0

Few days ago we upgraded our react-native app from version 0.68.0 to 0.70.6 using the React Native Upgrade Helper and have notice some performance issues in navigation as well as UI interactions in release mode also. So, recently we upgraded to 0.71.2 but still the application performance is not same which as at 0.68.0. We tried by enabling & disabling the hermes by results are same.

I’m unsure what is actionable for us on this issue. You’re mentioning generic “performance issue”. Which kind of issues are you referring to?

Awesome! I’m going to try everything asap and let you know. Thanks for the clarification ❤️

@kelset can you point us to the fixes so we can patch on older versions? In my case, I’m on v0.70.10 and experiencing app start time degradation on iOS but I can’t upgrade to 0.72 to test your fixes without a significant effort.

Update: App start times for iOS have dropped back to normal as of our upgrade to v0.70.10.

LOL upgrade RN = too heavy job. I have same performance problem too

@cortinico I saw the fix is still back and forth and waiting to be re-landed https://github.com/facebook/react-native/pull/37634 Can you clarify the bug is truly sorted out for both platforms in 0.72 or in main or still in investigation? Thank you

I’m on v0.70.10 and experiencing app start time degradation on iOS but I can’t upgrade to 0.72 to test your fixes without a significant effort.

As @cipolleschi mentioned, the useEffect bug we fixed in 0.72 can’t be easily backported. The reason is that this is a fundamental change in the internals of React and we can’t ship this change as a patch release for a stable release.

Unfortunately, the fixes are not easily backported: we have to update the JS scheduler and reroute the rendering to a native implementation of the RuntimeScheduler.

For example, for iOS:

• https://github.com/facebook/react-native/commit/dd9a5ab8a938f9f9ae0b3c117d8f432d7793bbc5
• https://github.com/facebook/react-native/commit/ee177cab7583fa305d43c66342fb9b3693a4769a
• https://github.com/facebook/react-native/commit/dc6a2c384db8acf59eba87bf75e435e51780204d
• https://github.com/facebook/react-native/commit/c43bd7a73a210ce9514ddf1fe8af33d9347f5d16

For Android:

• https://github.com/facebook/react-native/commit/47b45df65c104411339090d2b9c307402a8eb679

As you can see, these are not trivial changes to backport as the state of the repo evolved significantly after almost ~2k commits. 😦

@henrymoulton thank you that’s interesting.

Do you have control groups on that release (0.69/0.71 being the only change)?

Do you think changes (like this one could skew the comparison.

Just trying to account for variables.