Replies: 2 comments 2 replies
-
@sammy-SC does the new architecture support react 18 batch update and concurrent rendering? |
Beta Was this translation helpful? Give feedback.
1 reply
-
Can't build the benchmark project with the following error when running
Temporary I copy the JS files to App solve it. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The New Architecture Benchmarks
Thanks to everyone who created benchmarks to compare the old and New Architectures. These benchmarks have helped us to identify performance gaps in the New Architecture. I want to reassure our users that the React Native team is fully committed to rolling out the New Architecture without introducing any regressions.
We have prepared an app that consolidates several performance scenarios into a single place. The source code is available in Github repo with instructions how to install it and run the benchmarks. It has a way to switch between old and the New Architecture without the need to rebuild, making it easy to compare the two. It measures the time it takes to render results of an update on screen and display it on screen. Section "How we measured time to render for the benchmarks" covers this more in depth. The results are listed in "Results" section.
However, it is important to note that synthetic benchmarks like the ones used in these comparisons are not always representative of real-world scenarios. Therefore, we do not expect significant performance gains as a result of the migration to the New Architecture. Nonetheless, we believe in the benefits of the New Architecture and we are excited to bring it to our users.
How we measured time to render for the benchmarks
To measure how long an update takes, we need to have timestamps for two events: when the update is initiated and when the result is painted on the screen.
The update starts when the “Touch ended” event is triggered. “Touch ended” is triggered by the host platform on the UI thread when user lifts their finger off the screen. The event object passed to
Pressable.onPress
has this information under the timestamp key. We pass the timestamp together with a marker name to the native moduleRTNTimeToRender
** to store when the update was initiated. We can’t use the current time in JavaScript because the touch event happened earlier on UI thread.The update is finished when the results are painted on the screen. React Native does not provide a timestamp for when the results are painted on the screen out of the box. We will have to write a small native component that will do it for us. The native component has “marker name” as its prop. Using host platform APIs, we can precisely capture when the component was painted. Now we subtract the timestamp of when the update was initiated, stored in
RTNTimeToRender
, and we know how long it took to paint the result.Results
Each value presented here is an average of five measurements. The measurements were collected on physical devices running React Native 0.72.0-RC.1. It's important to note that these are synthetic benchmarks and may not reflect real-world usage of React Native. It's possible that migrating to the New Architecture may not result in performance improvements for your specific app.
Physical Device: Google Pixel 4
Physical Device: iPhone 12 Pro
Write your own performance scenario
If you're interested in comparing the performance of your own components between the old and New Architectures, you can easily do so by heading to App.tsx. Add your own code and follow the instructions in the README. The app will display the time it took to render your components. You can switch between the old and New Architectures using the buttons at the bottom. Happy testing!
Performance gaps
We discovered three performance problems in the New Architecture. One affecting both Android and iOS. One that is specific to Android and and one that is specific to iOS. These issues have been fixed in 0.72.0-RC.1.
The biggest deficit was caused by the missing
NDEBUG
compiler flag in optimized builds. TheNDEBUG
compiler flag is used to disable debugging features in C++ programs. Core of the New Architecture is written in C++, and without theNDEBUG
flag in optimized builds, the code performs debug only checks. The fix for this issue (Android, iOS) is available in 0.72.0-RC.1. These checks are for debugging only and must be removed in optimized builds for optimal performance.Additionally, we discovered redundant work in our text rendering infrastructure on both platforms.
On iOS, we were creating
NSTextStorage
twice for every<Text />
element: once to measure the size of the text for Yoga to layout other parts of the UI, and a second time to paint the text on the screen.NSTextStorage
is expensive to create and can be cached. This issue has been fixed and now rendering of 5,000<Text />
elements is 20% faster in the New Architecture.On Android, we found that React Native was re-measuring the same text multiple times with the same constraints. Measuring text in Android is expensive because it requires transferring text data from C++ to Java through JNI, creating
Spannable
objects, and finally calculating the layout. This logic has been optimized in this commit. Additionally, we added a second layer of caching in Android to avoid recreatingSpannable
Text
objects during rendering.Beta Was this translation helpful? Give feedback.
All reactions