Closed vaandhare closed 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", },
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:
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:
@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
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
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:
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:
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. :(
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.
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.
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.
Awesome! I'm going to try everything asap and let you know. Thanks for the clarification :heart:
@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
LOL upgrade RN = too heavy job. I have same performance problem too
@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.
I am trying to upgrade to 0.71.8 and hope for the performance ✌️
@fukemy 0.72 not 0.71
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.
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.
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).
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.
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.