react-native
react-native copied to clipboard
App performance is degraded when react native version updated to 0.71.2 from 0.68.0 on android
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.
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", },
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?
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
@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 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?
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
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
same issue
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
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
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 😄
This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days.
Not stale. Repro in #35778.
@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.
@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.
not sure if this helps but these issues might be related and some have a narrowed down cause with reproductions:
- https://github.com/facebook/react-native/issues/35778
- https://github.com/facebook/react-native/issues/36296
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)](https://user-images.githubusercontent.com/46665295/231019019-dfeff9d1-66d3-4180-96be-fdbb350dab79.png)
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
@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.
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.
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
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.
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!
This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days.
@kelset seems like someone opened a new issue #37335 for 0.71.7
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.
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?
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).
@vaandhare please create a repro.
@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.
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. :(
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.