Performance Issues with React Native Bridgeless Architecture #47490
Comments
santhoshkumarvgds
added
Needs: Triage 🔍
Type: New Architecture
|
Warning Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2. |
react-native-bot
added
Needs: Author Feedback
Needs: Repro
|
Warning Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2. |
|
Warning Missing reproducer: We could not detect a reproducible example in your issue report. Please provide either:
|
Yes we would need an isolated reproducer to look into this. |
|
I agree, there are lots of lags and crashes. |
|
i know this isnt particularly helpful to most others, but i also oberved performance degradation when migrating my app to bridgeless. my sprcific issue is react-navigation drawer opening is particularly choppy and wont switch screens completely. this is not exactly the rn teams fault, but the general DX/UX of our apps are still impacted |
|
@lovegaoshi did you manage to fix that choppy drawer animation? The new architecture heavily slows down my app, is there any timeline for fixing this? |
|
unfortunately no. im reliant on react navigation and react native paper,
and both have minor but unacceptable UX issues that i could not upgrade to
the new arch with. right now im reinventing the wheel to write my own ui
lib and migrate away from these ui libs.
given other important libs like rn firebase or notifee also breaks, its
peobably the best to not chase the newest feature.
…On Wed, Nov 13, 2024, 11:43 AM Joost ***@***.***> wrote:
@lovegaoshi <https://github.com/lovegaoshi> did you manage to fix that
choppy drawer animation? The new architecture heavily slows down my app, is
there any timeline for fixing this?
—
Reply to this email directly, view it on GitHub
<#47490 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMOVVT3NCGMGDL4IRIDT732AOTXLAVCNFSM6AAAAABRLKPMCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUGU4TKMJRG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I can also confirm that the new arch is causing a few performance issues regarding responsiveness, I can notice a significant lag in catching touch events when doing things quickly which may indicate the blocking nature of synchronous events? Also a few bugs where Views seem to always fade / animate when layout changes or Text with adjustToFitSize and "unacceptable" lineHeight completely bug out but these are different issues. |
|
Yeah the navigation and the overall responsiveness is horrible for me. I really hope this gets fixed because other than the performance issues, the new architecture is very promising. @santhoshkumarvgds are you able to create a minimal reproducible example? |
|
I just wanted to add that on our project (which is quite massive but well-maintained), we also see significant performance degradations in debug mode on RN 0.76, even with the new architecture turned off. The problem might be related to hermes, which has steadily declined in performance over the past few releases. Can anyone confirm that 0.76 + new arch disabled also causes performance regressions? |
|
I haven't tested without the new arch. But I can confirm that it's probably related to Hermes as the JS frames are very low which makes the app unresponsive. |
|
okay, im probably able to provide a repo soon(tm). i have a MotionLayout
equivalent component just built from scratch using reanimated and gesture
handler, and new arch is noticably choppier than old.
…On Thu, Nov 14, 2024, 10:49 AM Joost ***@***.***> wrote:
I haven't tested without the new arch. But I can confirm that it's
probably related to Hermes as the JS frames are very low which makes the
app unresponsive.
—
Reply to this email directly, view it on GitHub
<#47490 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMOVVQCYXGRUJDMZ7BAZVD2ATWENAVCNFSM6AAAAABRLKPMCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZXGE3TEOBUHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
here for android. I have a MotionLayout (black bar at the bottom) that drags to expand to fullscreen. This is fluid with the old arch, new arch without expo's stack component, new arch with flatlist, but choppy with new arch and expo's stack or flashlist. im not sure how useful this actually is, as this is an expo template (nowadays loaded with expo bloats. i used it for convenience) rather than a reproducer, and technically all react native components work as expected, just 3rd party libs are not. not sure who to ping to get visibility. |
|
We have similar issues both in Android and iOS for our app running RN 0.76.2. |
|
Unfortunately, I have to completely agree with this. I spent the whole week, full of anticipation and euphoria, painstakingly converting our app to the new architecture. |
|
@cortinico @cipolleschi any chance the React Native team can look into this with the reproducer from @lovegaoshi? It's not feasible for me to provide my company repo for obvious reasons, and creating a new project is not going to truly reflect the performance regressions in more complex applications. I find it hard to believe that Meta is using 0.76 internally unless it is really a case of user error, but it seems unlikely as many people are facing this issue. To reiterate, here is my "minimally reproducing setup" on a complex application:
Performance is terrible on debug builds but seemingly faster than 0.75 on production, so the performance impact is only felt in debug mode. However, it makes for a horrendous development experience. Making changes and interactions take seconds. I believe 0.76 has been the most insidious upgrade cycle because the changes according to the upgrade helper are minimal, but there are so many invisible moving parts under-the-hood that makes it impossible for us to have a reasonable timeline for any action items to pinpoint any sort of root cause. Many of us have to build features for our companies and upgrading should not be this tedious. Although I greatly appreciate the work that the Meta team have put into this release, it has been an impossible one for us, and this is very worrying for the future of my company project due to the tight deprecation cycles in the React Native ecosystem. |
|
@thespacemanatee I'm so sorry to hear that it is not working for you.
At Meta we use React Native from main, the latest commit available, and yes, all our internal app are using or are migrating to the New Architecture. We might have some extra fix that we shipped between the branch cut of 0.76 (beginning of September) and today, but I can't think of anything that might dramatically change the performances of the app running in Debug. Is this happening for Android, iOS, or both of them? Without a reproducer is pretty hard for us to do any work. The issue you are facing might be coming not from React Native core but from some external libraries you are using. Multiple people are reporting the issues, so I'm not downplaying them, I'm sure they are there and real. It would be quite helpful to try and find the minimum common denominator of the set of libraries or patterns that are causing the slowness. |
|
@cipolleschi Thank you so much for the response.
Both of them are slow in debug mode. Both are fast in production mode. On our end, we will try to reverse engineer and determine whether an external dependency is causing this debug performance regression. The current list of dependencies we are using is reputable though as far as I can tell, comparing it against https://reactnative.directory/. Also, CMIIW, but Bluesky is still using RN 0.74? Do they have a branch where they have validated that 0.76 + New Arch runs smoothly? EDIT: They have a 0.76 branch that seems to be inactive currently, maybe someone from the team can chime in about the issues they are facing with upgrading. |
|
Small consolation, but for those of you running react navigation as your navigation package, it appears that native stack navigators run slightly faster than "normal" stack navigators for screen transitions. |
|
@thespacemanatee can you try something for me. On iOS, can you try to modify the def self.add_ndebug_flag_to_pods_in_release(installer)
ndebug_flag = " -DNDEBUG"
installer.aggregate_targets.each do |aggregate_target|
aggregate_target.xcconfigs.each do |config_name, config_file|
- is_release = config_name.downcase.include?("release") || config_name.downcase.include?("production")
- unless is_release
- next
- end
self.add_flag_to_map_with_inheritance(config_file.attributes, 'OTHER_CPLUSPLUSFLAGS', ndebug_flag);
self.add_flag_to_map_with_inheritance(config_file.attributes, 'OTHER_CFLAGS', ndebug_flag);
xcconfig_path = aggregate_target.xcconfig_path(config_name)
config_file.save_as(xcconfig_path)
end
end
installer.target_installation_results.pod_target_installation_results.each do |pod_name, target_installation_result|
target_installation_result.native_target.build_configurations.each do |config|
- is_release = config.name.downcase.include?("release") || config.name.downcase.include?("production")
- unless is_release
- next
- end
self.add_flag_to_map_with_inheritance(config.build_settings, 'OTHER_CPLUSPLUSFLAGS', ndebug_flag);
self.add_flag_to_map_with_inheritance(config.build_settings, 'OTHER_CFLAGS', ndebug_flag);
end
end
endThen reinstall pods and try again? What this does is basically to set the NDEBUG flag to every build config. This should disable some expensive runtime checks we are doing in debug mode to ensure the correctness of the framework. Those checks are disabled in production so that could be one of the causes why Debug is slower than development. AFAIK, Bluesky made an Android release with the New Architecture that they asked users to try. I think they are also doing a phased rollout using the Play Store, but I am not completely sure. |
|
@cipolleschi Thanks for the suggestion but unfortunately it's still as slow as before, though at least we can probably rule out NDEBUG as the root cause. |
|
To set expectation, I'll be off next week and @cortinico will be back on Thursday. We will try to prioritize this once we are back. |
|
I guess Text in particular has issues in Fabric, honestly most of our app was fine in the upgrade, outside of some visual regressions and third party library crashes. Resource intensive screens (many api calls, streaming updates, etc) seem to have suffered and require different strategies that are GPU based like Skia It's hard to say if this is RN or a combination of RN and third party libraries. The thing is when I profile text updates on Paper for Android it's still pretty bad if it's very fast Another thing is that even opening an RN base modal jitters on heavy computational pages, not sure what's going on there |
|
Guys, without a repo or snack is IMPOSSIBLE to help. @pleerock can't you put that emoji component in a expo snack and share with us? You can create 2, one in SDK 51 (old arch) and another in SDK 52 (new arch), it will have the same code and it's very fast to do. |
|
After digging a bit more I don't actually think Text has regressed itself, I think there's something fishy with react-navigation and screens in the background continuing to update and destroy FPS 🤔 @wfern I will try to put together a reproducer but trying to get something together that emulates a large production app is difficult |
|
hey folks, reanimated 3.17.0 is out with some memory leaks fixes, can someone upgrade and test it out? |
|
@efstathiosntonas It seems to be stable, it doesn't help with the FPS issues I mentioned or the KeyboardAvoidingView not triggering |
|
I've got another pointer, though probably not applicable to many others on this thread. My app uses a bunch of self-updating hooks while the app is in the background. I found some of them will cause a severe performance degradation when the app is minimized for a long time (5 min) then resumed, only in the new arch. The screen either froze for 5s+ or became a white screen of death. My hypothesis is adding a check if Appstate is not active before the setState will solve this issue. |
|
Can the React Native maintainers give us updates ? New versions are released, but the same problems persists with performance degradation and fps drops when enabling the new architecture. |
I'm following this thread, but I still have to see a reliable reproducer/video that we can look into. Without reproducers we can't really help you folks, you might be writing code that this is just not performant. Or there could be a bug inside the core of React Native. Sadly without seeing your projects there is not much we can do. |
Bule sky seems to have same issue too, You could check it. |
|
At least for me, I have a really hard time reproducing my performance issue on a small scale reproducer - it is quite apparent in my app, but when u take out the bells and whistles the performance lag becomes acceptable/unnoticeable. With that said if anyone just need a project to show that the new arch has performance issues, heres mine. I have newarch and oldarch both compiled on android with the only difference between them is simply enabling the flag. Throughout use, the miniplayer animation becomes noticeably laggier when there is media playing in the new arch, on my Samsung S21. All I know as a dev is I switch to newarch with one line, and I see lag. If the old arch works fine I dont really see the point being only me writing crap code. It could be me having a lot of data/assets loaded in the app while I'm using it, it could be my phone is not particularly strong anymore, it could be only via prolonged period of use that eg. the expo people refused to acknowledge my app has issues. I do know quite a few newarch workarounds at this point from debugging my mess - one being the flex calculation when there is a resizing event is much slower than old. I have to pin the view height instead of using flex for the new arch. This directly apply to the miniplayer animation I mentioned above and was a major source of performance degradation for my app. Another being updating states while the app is in the background will cause a major lag/white screen of death when the app is resumed on android. |
|
Maintainers have been pretty diligent about tracking down New Architecture performance regressions in other cases when those are clearly demonstrated. If someone can demonstrate a specific issue using React Native Reproducer with example code I think this'll be addressed much faster. |
|
Hello @cortinico, I previously provided a minimal reproduction but haven't received any feedback on it, except from @kirillzyusko, who suggested trying the new version. After switching to version 0.76.5, the crash issue was resolved. However, performance issues persist on both iOS and Android. Due to the nature of the projects where we are experiencing these issues, it's quite difficult to create a minimal reproduction. Nevertheless, I have partly open-sourced my project and reduced it as much as possible here: GitHub Repository. This is a New Architecture-enabled project that I have been developing for the past five months, and it relies heavily on @shopify/flash-list and @gorhom/bottom-sheet. While testing, I noticed that screens with only a single element perform well and work perfectly. However, if you navigate to src/app/(app)/(tabs)/account.tsx, enable ProfileView, and comment out the component (which I have already done), performance issues immediately appear. Once enabled, navigating between screens becomes extremely laggy. Digging further, I disabled ProfileView again (which is just a simple ScrollView with some links in it) and navigated to the home screen (src/app/(app)/(tabs)/home.tsx). There, I enabled FilterTagList, which is a FlashList that, as you know, uses C++ at its core. Once enabled, the lagging starts instantly. Looking even deeper, the @gorhom/bottom-sheet package performs very poorly with the New Architecture. Since it heavily depends on react-native-gesture-handler and react-native-reanimated, it seems to struggle with performance. In the production-ready version of my app, with all its features enabled, memory leaks occur in the New Architecture, and I see logs related to react-native-reanimated trying to access and modify a shadow node, which causes crashes: I have reduced the base code as much as possible, but in order for you to see the modals and bottom sheets, I have kept the map and the secrets in an .env file. For security reasons, I will change them once you confirm that you have investigated the reproduction. Any feedback is welcome, and I am happy to make adjustments based on your revisions and suggestions. The issues are similar on Android as well. Additionally, Dan Abramov commented on this issue, mentioning that Bluesky is also experiencing similar problems and that they will investigate further. Has there been any development on this? Have they identified the root cause of the issue? |
|
The problem may come from react-native-reanimated. I’ve been guessing that for some time. I have had problems with this package in the past, so it would not be really surprising |
Yeah logs seem to point us in that direction but @lovegaoshi s find is also interesting. Scrollview's that has flex: 1 on their style prop and flexGrow: 1 on their contentContainerStyle seem to cause performance issues because of the way height is calculated on the new arch. Maybe contributers can focus on these two points on the example, I provided both. I kept the ProfileView example especially for that |
|
After a lot of individual profiling of various parts of the ecosystem I came to find most of the performance issues stem from 3rd party libraries @ustuncem we noticed the same behaviour with gorhom, however we are just looking to remove our usage. The library is needlessly complex. In terms of navigation becoming laggy I found that this is mostly due to the lack of virtualization (usage of flatlist/sectionlist) for complex screens when profiling with the react profiler. This lag would subside, |
|
We have specifically seen extreme performance degradation when upgrading from 76 to 77 last week, with new arch enabled. Both iOS and Android. Has anyone else noticed degradation specifically around that update? We have begun to investigate & debug, will report back if we find anything. |
Hello @mobinni thanks for the response. I have been using bottom-sheet since its version 3 was released and it was working fine up until now, new architecture era of the react native. I am fine with migrating and implementing my own bottom sheet solution but I dont think its the root cause of this issue. ShadowNode commitments to update the UI from reanimated is leaking some memory and I think that's the core reason why reanimated based packages aren't working performantly(react-navigation, bottom-sheet, basic libraries that every project installs instantly when any of us inits a react native project). Also I am using FlashList and that's also leaking memory because of the same reason reanimated is not performant. Upon scrolling up and down on FlashList for performance, views that aren't visible on the viewport are removed from the ShadowTree and that's commited also using React Native's ::commit function. Scroll a few times and boom the app crashed and logs that :commit function killed a thread in the system. I don't know which action to take other than provide a minimal reproduction for this issue so if anyone can point me in a direction I am more than happy to take action to solve this problem. If I should talk with the reanimated guys or flashlist guys or basically anyone that uses the C++ bridge and uses the ShadowNode::commit function, I am happy to start threads there also |
|
@ustuncem Sorry I didn't mean to say that the root cause of this isn't related to the new architecture, personally I have just fought with the bottom sheet library for too long 😅. However it isn't react-native, but reanimated that plays a big role here. Which I believe is being addressed here - software-mansion/react-native-reanimated#6776 In terms of the flashlist performance, I have not noticed similar issues, and we use it quite extensively. Happy to take that one offline and see if we can find a fix for your use-case @BenIrving We went from 0.76 to 0.77 and did not notice any significant drop-off. Is it isolated to a particular flow in your app or systemic? |
|
@mobinni did you have the new architecture enabled in versions 0.76 and 0.77? |
|
@DorianMazur yes we did have new arch enabled on both. Most of our performance regressions were honestly either screens doing too much processing that hadn't been maintained and/or bugs with reanimated/reat native screens etc |
It's systemic to all of the apps that we have. Interestingly, upgrading to 78 resolved the issues we saw. |
|
@mobinni Do you have any patches for the mentioned libraries? How did you solve these bugs? It would be really helpful if you could share more details. Thanks! |
|
Hello @BenIrving are you using expo? I use expo and will try to migrate if the issues are solved in v0.78. Can you share the package versions that you are using so I can try with the working packages, especially reanimated related ones. Thanks in advance |
|
I think the root cause is mentioned and highly discussed since December here: software-mansion/react-native-reanimated#6776 as @mobinni mentioned. It looks similiar to our problems discussed in this thread also. When the ShadowNode commit function is runned via an external library something happens that causes apps to crash or lag which seems to point us that a lot of libraries that are widely used aren't ready yet for the new architecture and we have to wait for them to get stable and adapt to the new changes. If anyone that has successfully migrated to the new architecture like @mobinni can share their experience and how they solved this pin points it would be amazing for us that are struggling. |
|
The issue from 6776 isn't really performance related. It's mostly concerned with a wrong state being mounted. Upgrading to 0.78 might resolve your issues. We had a problem, where Hermes would perform a heavy |
|
@bartlomiejbloniarz Anecdotally I did not see any noticeable improvements between architectures on 0.77 or 0.76 and I ran both in both modes. In 0.73 I did see that the old arch was slightly better on Android overall so this makes sense. Is there a way to backport the patch if we're not ready for 0.78 and react 19? Based on this thread as well it seems that this mainly affected JS calls to JSI functions, so heavy worklet based threads in reanimated, etc. ? I guess that doesn't mean that other libraries won't get a massive boost from this, I just have limited insight into what other libraries would suffer from this issue. |
|
@DorianMazur it depends on the package and the use-case, from the bugs we found here are some current guidelines that don't address the root cause but unblock:
|
|
@mobinni The issue that I described affects only reanimated (and packages that use reanimated). You would have to build React Native from source and apply the mentioned PR. Other libraries could suffer from the fact that lots of time is wasted on those stack overflow checks triggered by reanimated usage of the Hermes runtime. But it's also very likely that this isn't the only issue that people in this thread experience. |
|
@bartlomiejbloniarz I think there was a line that could be added on edit: I might be totally wrong though edit 2: I believe It's on |
|
@efstathiosntonas I'm not sure that using different versions of Hermes and React Native is the safest option, there might be some mismatches, as they are not tested together. |
and others
Description
The Bridgeless Architecture in React Native 0.74 and later introduces significant performance issues, particularly for apps with complex logic and high demands for UI responsiveness. Here are the main concerns:
Key Issues
1. Screen Load Times
2. UI Responsiveness and Touch Lag
3. Lazy Module Loading
Comparative Performance with Older Versions
Attempts to Improve Performance
Call for Optimizations
The React Native community and core team are urged to provide optimizations or alternative solutions to enhance performance under the bridgeless architecture.
Feedback Needed: Community support and solutions for the architectural limitations causing these performance issues.
Steps to reproduce
Expected: Slower performance in the bridgeless versions.
React Native Version
0.74+
Affected Platforms
Runtime - Android, Runtime - iOS
Areas
Bridgeless - The New Initialization Flow, Other (please specify)
Output of
npx react-native infoStacktrace or Logs
Reproducer
Reproducer: Unfortunately, I cannot provide a public repository or Expo Snack at this time. Please let me know if you would like further details or an isolated example of the issue.
Screenshots and Videos
No response
The text was updated successfully, but these errors were encountered: