facebook / react-native

A framework for building native applications using React
https://reactnative.dev
MIT License
119.43k stars 24.37k forks source link

App performance is degraded when react native version updated to 0.71.2 from 0.68.0 #36123

Closed vaandhare closed 1 year ago

vaandhare commented 1 year ago

New Version

0.71.2

Old Version

0.68.0

Build Target(s)

Android 8 to Android 13

Output of react-native info

System: OS: macOS 12.6.1 CPU: (8) arm64 Apple M1 Memory: 147.81 MB / 16.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 18.0.0 - ~/.nvm/versions/node/v18.0.0/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 8.6.0 - ~/.nvm/versions/node/v18.0.0/bin/npm Watchman: 2022.11.14.00 - /opt/homebrew/bin/watchman Managers: CocoaPods: 1.11.3 - /Users/vaibhavandhare/.rbenv/shims/pod SDKs: iOS SDK: Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1 Android SDK: Not Found IDEs: Android Studio: 2022.1 AI-221.6008.13.2211.9514443 Xcode: 14.1/14B47b - /usr/bin/xcodebuild Languages: Java: 11.0.17 - /usr/bin/javac npmPackages: @react-native-community/cli: Not Found react: 18.2.0 => 18.2.0 react-native: 0.71.2 => 0.71.2 react-native-macos: Not Found npmGlobalPackages: react-native: Not Found

Description

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.

vaandhare commented 1 year ago

Addtional:

For version 0.68.0 "dependencies": { "@react-native-async-storage/async-storage": "^1.17.3", "@react-navigation/drawer": "^6.4.1", "@react-navigation/native": "^6.0.10", "@react-navigation/native-stack": "^6.6.1", "react": "18.2.0", "react-native": "0.68.0", "react-native-job-queue": "^0.5.0", "react-native-reanimated": "^2.6.0", "react-native-safe-area-context": "^4.2.4", "react-native-screens": "^3.13.1", "react-native-vision-camera": "^2.15.2", "react-native-webview": "^11.18.1", "react-redux": "^7.2.8", "realm": "^11.0.0-rc.0", "redux": "^4.2.0", "redux-persist": "^6.0.0", "redux-thunk": "^2.4.2", },

For 0.70.6 "dependencies": { "@react-native-async-storage/async-storage": "^1.17.3", "@react-navigation/drawer": "^6.4.1", "@react-navigation/native": "^6.0.10", "@react-navigation/native-stack": "^6.6.1", "react": "18.1.0", "react-native": "0.70.6", "react-native-job-queue": "^0.5.0", "react-native-reanimated": "^2.6.0", "react-native-safe-area-context": "^4.2.4", "react-native-screens": "^3.13.1", "react-native-vision-camera": "^2.15.2", "react-native-webview": "^11.18.1", "react-redux": "^8.0.5", "realm": "^11.3.1", "redux": "^4.2.0", "redux-persist": "^6.0.0", "redux-thunk": "^2.4.2", },

For 0.71.2 "dependencies": { "@react-native-async-storage/async-storage": "^1.17.11", "@react-navigation/drawer": "^6.5.8", "@react-navigation/native": "^6.1.3", "@react-navigation/native-stack": "^6.9.9", "react": "18.2.0", "react-native": "0.71.2", "react-native-job-queue": "^0.5.0", "react-native-reanimated": "2.14.2", "react-native-safe-area-context": "^4.5.0", "react-native-screens": "^3.19.0", "react-native-vision-camera": "^2.15.4", "react-native-webview": "^11.26.1", "react-redux": "^8.0.5", "realm": "^11.4.0", "redux": "^4.2.1", "redux-persist": "^6.0.0", "redux-thunk": "^2.4.2", },

cortinico commented 1 year ago

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?

ClenildoCardoso commented 1 year ago

Também tive problemas com a versão 0.71.2.

Quando navego em meu app, ao tentar voltar para a tela anterior recebo o seguinte log:

Fatal Exception: com.facebook.react.common.JavascriptException TypeError: undefined is not a function This error is located at: in CountDown in RCTView in Unknown in RCTView in Unknown in RCTView in Unknown in RCTView in Unknown in QuizDirecaoDefensiva in StaticContainer in EnsureSingleNavigator in SceneView in RCTView in Unknown in MaybeNestedStack in RCTView in Unknown in RNSScreen in AnimatedComponent in AnimatedComponentWrapper in Suspender in Suspense in Freeze in DelayedFreeze in InnerScreen in Screen in SceneView in Suspender in Suspense in Freeze in DelayedFreeze in RNSScreenStack in ScreenStack in NativeStackViewInner in RNCSafeAreaProvider in SafeAreaProvider in SafeAreaProviderCompat in NativeStackView in PreventRemoveProvider in NavigationContent in Unknown in NativeStackNavigator in EnsureSingleNavigator in BaseNavigationContainer in ThemeProvider in NavigationContainerInner in App in RCTView in Unknown in RCTView in Unknown in AppContainer, js engine: hermes, stack: componentWillUnmount@1:731758 commitDeletionEffectsOnFiber@1:286834 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287154 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287393 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287004 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287154 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287393 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287004 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287154 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287393 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287004 recursivelyTraverseDeletionEffects@1:286598 commitDeletionEffectsOnFiber@1:287154 recursivelyTrav<truncated: 2955 chars>

Sendo que na versão 0.68 eu não tinha esses problemas

vaandhare commented 1 year ago

@cortinico Application works smoother in v0.68.0 than in v0.70.6 & 0.71.2 in terms of navigation, button clicks, etc. We keep the same versions of other dependencies.

cortinico commented 1 year ago

@cortinico Application works smoother in v0.68.0 than in v0.70.6 & 0.71.2 in terms of navigation, button clicks, etc. We keep the same versions of other dependencies.

Could you provide evidence in the form of a reproducer or gifs that shows your problem side by side?

minhna commented 1 year ago

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

XFAISAL commented 1 year ago

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

furkanuzundev commented 1 year ago

same issue

tj-mc commented 1 year ago

Experiencing this starting from 0.70.5. In low-power mode on iOS, everything is much worse. Cannot share a repo unfortunately. React Navigation 6

stephanrotolante commented 1 year ago

RN Version 0.71.3 Same here! One thing to note that the views on my app are slow when you initially go through them, but after you've gone through them a few times the speed is back to normal

tj-mc commented 1 year ago

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 😄

github-actions[bot] commented 1 year ago

This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days.

tj-mc commented 1 year ago

Not stale. Repro in #35778.

henrymoulton commented 1 year ago

@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:

image

90th Percentile:

image

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.

blakef commented 1 year ago

@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.

KrisLau commented 1 year ago

not sure if this helps but these issues might be related and some have a narrowed down cause with reproductions:

tj-mc commented 1 year ago

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.

Screen Shot 2023-03-06 at 9 09 43 am (1)

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:

cipolleschi commented 1 year ago

@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

tj-mc commented 1 year ago

Hi @cipolleschi 😄

I attempted to upgrade to to 0.71.x, but it is quite a complex diff for our app and I didn't have the time to get it working. However I did these tests comparing 0.69.8 and 0.70.1, which I hope may still be useful for ruling things out.

I built the app with PRODUCTION=1 bundle exec pod install but did not notice an improvement in startup time or memory usage. I was only able to test on simulator, but It seems to behave the same as hardware.

Frame 1

LEFT: 0.69.8 bundle exec pod install RIGHT: 0.70.1 PRODUCTION=1 bundle exec pod install

https://user-images.githubusercontent.com/46665295/231908485-a5054b53-9499-4685-8ccd-5a028b0a277d.mp4

conoremclaughlin commented 1 year ago

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.

kelset commented 1 year ago

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

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!

github-actions[bot] commented 1 year ago

This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days.

KrisLau commented 1 year ago

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

cortinico commented 1 year ago

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.

kelset commented 1 year ago

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?

vaandhare commented 1 year ago

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).

kelset commented 1 year ago

@vaandhare please create a repro.

Ingibjorg commented 1 year ago

@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.

cipolleschi commented 1 year ago

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:

For Android:

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

cortinico commented 1 year ago

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.

diegolmello commented 1 year ago

I couldn't try 0.72 on our app because Expo didn't support it (at least it didn't 3 weeks ago), but this comment says it's not completely fixed https://github.com/facebook/react-native/issues/36296#issuecomment-1584844669

My main issue with this is that the deadline to support Android SDK 33 is in a few months and we need to upgrade RN to do it. Until then we can safely stay on 0.69.8.

cortinico commented 1 year ago

I couldn't try 0.72 on our app because Expo didn't support it (at least it didn't 3 weeks ago), but this comment says it's not completely fixed #36296 (comment)

@diegolmello Nope that comments mentions generic performance regression with a calendar libray. The problem is that we receive 'generic performance regressions' issues over and over, and it's hard to pinpoint where the issue is, especially if the issue is in a 3rd party library.

So far, we isolated a bug with useEffect which we fixed and we released in 0.72. Expo will come up with SDK 49 soon which will include this fix.

diegolmello commented 1 year ago

Awesome! I'm going to try everything asap and let you know. Thanks for the clarification :heart:

sunnylqm commented 1 year ago

@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

fukemy commented 1 year ago

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

efstathiosntonas commented 1 year ago

@fukemy you do realize rn is still on 0.xx right? You acknowledge that breaking changes are introduced on every new major release, right? Upgrading is hard, yes, but sometimes is you’ll have to do it otherwise you have code debt that eventually it will become unbearable to handle.

fukemy commented 1 year ago

I am trying to upgrade to 0.71.8 and hope for the performance ✌️

efstathiosntonas commented 1 year ago

@fukemy 0.72 not 0.71

tj-mc commented 1 year ago

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.

vaandhare commented 1 year ago

I have created new application with 0.72.0 version, I can see performance improvement as compared to 0.71. But with navigations in v0.68 is still better.

piuholo commented 1 year ago

Anecdotal, but this is our experience with the issue:

In our case, the issue seems to only affect Android, unlike for some of the other developers in this thread. Perhaps it is because we are using Hermes engine only on Android and JSC on iOS. Additionally, this performance issue has been extremely hard to reproduce and profile. We have seen no significant memory or CPU usage increase when comparing 0.68 and 0.71 or 0.72 on multiple generations of Android devices. Yet, it is undeniable that the performance took a big hit after upgrading React Native, on non-insignificant portion of Android devices in the real world (but not all of them).

kelset commented 1 year ago

Hey everyone - I talked with @cortinico and we have decided to deduplicate this "performance regression post 0.70" conversation in this issue to try and keep the comments meaningfully relevant all in the same spot and avoid having to literally post the same comments in the both.

Please head over to #36296 and check out the status update on the maintainers end on this problem.