facebook
Very long re-rendering times in 0.71.3
For the latest update on this situation, please refer to this comment.
Description
I have a complex calendar component in my app. I previously ran it on 0.66.5, where it was really fast, but after upgrading to 0.71.3, performance dropped drastically, to the point that it is unusable.
The problem is most obvious on ios, but also appears on Android.
I used to react devtools in flipper to measure the re-render times. On ios in 0.66.5, the component re-rendered in about 7ms, on 0.71.3 it took nearly 400ms. On android the 0.66.5 took about 10ms, 0.71.3 took about 30ms.
The app uses dayjs and Flashlist, but performance was the same when switching to regular Flatlist.
React Native Version
0.71.3
Output of npx react-native info
System: OS: macOS 13.0.1 CPU: (8) arm64 Apple M1 Memory: 139.16 MB / 16.00 GB Shell: 3.3.1 - /opt/homebrew/Cellar/fish/3.3.1/bin/fish Binaries: Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node Yarn: 1.22.17 - ~/.nvm/versions/node/v16.13.0/bin/yarn npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm Watchman: 2022.01.17.00 - /opt/homebrew/bin/watchman Managers: CocoaPods: 1.11.2 - /opt/homebrew/lib/ruby/gems/3.0.0/bin/pod SDKs: iOS SDK: Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1 Android SDK: API Levels: 29, 30, 33 Build Tools: 29.0.2, 30.0.2, 30.0.3, 33.0.0 System Images: android-30 | Google APIs Intel x86 Atom, android-S | Google APIs ARM 64 v8a Android NDK: Not Found IDEs: Android Studio: 2020.3 AI-203.7717.56.2031.7678000 Xcode: 14.2/14C18 - /usr/bin/xcodebuild Languages: Java: 11.0.18 - /usr/bin/javac npmPackages: @react-native-community/cli: Not Found react: 18.2.0 => 18.2.0 react-native: 0.71.3 => 0.71.3 react-native-macos: Not Found npmGlobalPackages: react-native: Not Found
Steps to reproduce
Run the application and click on any day in the calendar. It has a visible lag between the click and the reaction.
Snack, code example, screenshot, or link to a repository
This is an example on 0.71.3: https://github.com/MichalBBBB/react-native-calendar This is an example on 0.66.5: https://github.com/MichalBBBB/react-native-calendar-old
Hello, I also found this issue after upgrading react-native from 0.65+ to 0.71+. For example, JSON.stringify() of around 10000 characters took 0.007 second to complete on 0.65+, while 0.71+ took around 0.08 second to complete. Looking at the numbers, this took 1042% longer then old version.
For someone who may interested in hermes-engine, it will just results in more and more time cost :( (around 0.8 second).
Right now I'm trying to figure out which version of react-native will causing this issue, will keep update here.
After a long debugging, I found that it is more like the problems of react-navigation and react-redux, not because of the react-native, although it really became more slower after enabling the hermes-engine.
Anyway, after downgrading the react-navigation from v6 or v5 to v4 , the performance regression problem disappeared, even if it is based on the react-native v0.71.3 and react v18.2.0. I also tried to downgrade the react-redux to v1.3.0 or even 1.0.0, but it was not helpful for the debugging.
This looks like starting from v5 of react-navigation have changing its render() operation, which also causes different performances from v4 every render(), especially in the component which based on the connect() of react-redux.
But so far I can't find related discussions on the repository of react-navigation, and I haven't found a solution to solve this problem, because @react-navigation/native-stack is also obvious for performance regression.
Since the problem I have faced after debugging is found that not really due to react-native, I am not good at continuing to discuss it here, but if you have any ideas for this, please continue to discuss.
The problem is the sample apps I provided use neither react-navigation, nor react-redux I have already made some modifications to the original component to improve performance, but it is still at least 5 times slower than the older version without these improvements
@MichalBBBB Do you find that the issues are worse in low power mode? We have noticed a general reduction in performance but severe animation freezes / navigation issues on iOS in low power mode, and for all android devices.
Но до сих пор я не могу найти соответствующие обсуждения в репозитории
react-navigation, и я не нашел решения для решения этой проблемы, потому что@react-navigation/native-stackэто также очевидно для снижения производительности.Поскольку проблема, с которой я столкнулся после отладки, оказалась не совсем из-за
react-native, я не могу продолжать обсуждать ее здесь, но если у вас есть какие-либо идеи на этот счет, пожалуйста, продолжайте обсуждение.
please send links to discussions in other repositories to follow the topic
@MichalBBBB Do you find that the issues are worse in low power mode? We have noticed a general reduction in performance but severe animation freezes / navigation issues on iOS in low power mode, and for all android devices.
The performance drop is always present on the iPhone, though I don't see that big of a problem on android
In our case the difference was most notable in startup time. From 0.69.7 to 0.70.7: Startup time doubled, and memory usages almost tripled.
Old, I just downgraded back to 0.69.8, which seems to be the newest version without these performance problems.
After upgrading from 0.68.2 to 0.71.3, we're seeing a similar slowdown across the app but it's especially apparent on screens that re-render themselves upon focus. Here's an example of the slowdown where all libraries are the same, except react and react-native:
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
Edit: Note these were compiled jsc and hermes is unfortunately worse so there may be two issues between the hermes build artifacts that had a fix pushed and the overall architecture changes that are slowing down both.
We're also experiencing a significant performance degradation ever since we upgraded from 0.6x to 0.71.x and seems like we're not the only ones #36123 .
Has anyone downgraded back to 0.6x ever since noticing this?
Is there any way to mitigate / minimize the impact? I've found the root cause way too late to downgrade.
#36123 Yes in our case we reverted to 0.69 and our performance was back to normal.
@tj-mc which version of React are you using with 0.69? Did you only downgrade react-native?
Maybe it’s related to this: https://github.com/facebook/react-native/commit/b07cf33279844d30920d8d46edb48b10ed5a1614
garbage collector seems to be not collecting at all [email protected]
I have a Flatlist used in a chat room with all the perfomance tips applied from the official docs. With Hermes enabled the memory skyrockets from ~450MB to 1.4GB while scrolling and when navigating away from this screen the memory is not de-allocated. I've disabled Hermes and the memory is going up to ~650MB and GC is working fine when navigating away.
Can anyone else confirm that there are memory leaks using Leaks measurement from Xcode Instruments?
edit: One other thing that I noticed that a cold boot of the app takes ~200MB of memory without Hermes, with Hermes the idle cold boot memory is ~500MB.
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!
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!
The application began to fly! Thank you so much, finally)) All freezes have disappeared (v0.71.7)
@kelset just updated to 0.71.7 and the memory leak from the comment above seems to be improved but it's nowhere near the non-Hermes build low memory usage/gc. At least now I'm topping at ~900MB instead of 1.4GB on 0.71.6.
Idle memory is again at ~500MB while on non-Hermes it sits around ~200MB. Don't know if this is normal or not, can't remember what was my idle memory consumption on previous react-native versions.
ps. it doesn't matter if I use FlashList or Flatlist, the gc won't work when exiting the screen, I'm using the latest navigation and react-native-screens versions using native stack navigator.
ps2. Cleaned derived data / build folder, pod deintegrated, deleted node_modules and yarn.lock, reinstalled everything.
I'll try to create a minimal example and try to reproduce and I'll create a new issue since I'm hijacking this one.
Just want to add to this, I also updated to 0.71.7 and still seeing massive performance issues, when i disable hermes on both expo and react-native cli, the performance is much better.
In case anyone is having pod installation issues while building their react-native iOS applications after disabling hermes, I found the comment in this issue helped me resolve them: https://github.com/facebook/react-native/issues/26118#issuecomment-525085809
We upgraded to 0.71.7 and didn't see any performance improvement on Android, since the change is iOS only. I am not sure if it's clear that this problem was originally reported for both platforms.
@kelset Guys, this is really bad. Our app became basically unusably slow (even with the new 0.71.7 patches) for our users when we pushed it to them and we had to do an emergency downgrade.
If this can't be fixed properly maybe recommend developers stay on 0.69 for now?
@TristanH We’ve encountered a similar large-scale issue in production, though only on Android. Did you see this slowness issue affect both platforms or only one of them?
Hey all, Nicola here from the React Native core team.
To bring clarity to this issue (which is similar to #37335 and #36123): 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?