React Native Memory profiling (JSC vs V8 vs Hermes)
We were facing memory issue with our Android app @WalmartLabs as stock JSC was doing minimal garbage collection in Android. We tried various options to reduce the memory footprint of our app with no success.
The problem becomes severe with react native flat list with a huge number of items (~1k in our case). The memory kept on growing with each navigation between the screens and didn’t come down even after clearing the data.
Savior
In Mid of June 2019, @kudochien tweeted about react-native-v8 package which can enable us to bundle V8 with react-native for android instead of JSC.
During the same time, jsc-android released a newer version 245459.0.0 and Hermes was announced during @ChainReactConf.
Hence, we decided to compare memory footprints of Stock JSC (v241213.1.0), new JSC(v245459.0.0), Hermes and react-native-v8.
To mimic a real-world use case, we created a sample repository.
We considered below use cases:
- Flat list with ~1k items
- Huge array list to mimic storing/removing large record (one record was new Array(999999).join(‘ — ‘)) in react state
- Memory footprint with react-navigation
ABI used -> x86_64
Observations
TL;DR
New JSC v241213.1.0 handles memory better than its previous version v241213.1.0, followed by Hermes.
However, react-native-v8 beats them by a huge margin in app startup memory, handling the memory of a flat list, handling the memory footprint of large data and most importantly garbage collection.
Sample APP
Steps
- Home -> flat list
- Scroll till last item (870 items) -> Home
- Memory hungry Array -> add record (100) -> remove -> Home
- flat list -> Memory hungry Array -> add record (100) -> Home
Results
Stock JSC (v241213.1.0)
It was the worst performer among three. Memory footprint was very high with minimal garbage collection
App startup memory(MB) — 59 (total), 20 (JS)
After flat list loaded(MB) (870 items) -> 239(Total),128 (JS)
After adding records (app crashed after adding 16 records) (MB) -> 1153(Total),1098(JS)
Garbage collection — minimal
Memory consumption graph
New JSC (v245459.0.0)
It was better than Stock JSC in handling memory and garbage collection.
App startup memory(MB) — 53 (total), 15 (JS)
After flat list loaded(MB) (870 items) -> 191(Total),107 (JS)
After adding records (MB) -> 714(Total),596(JS)
Garbage collection -> Yes, memory came down to 234 MB (Total), 121 MB (JS)
Memory consumption graph
React-Native-V8
App startup memory(MB) — 40 (total), 9 (JS) [↓ 55% (JS)]
After flat list loaded(MB) (870 items) -> 105(total), 36 (JS) [↓ 70% (JS)]
After adding records (100) -> 82(total),25(JS) [GC ran in-between]
Garbage collection -> Yes,max memory reached 103 MB(total), 36 MB(JS) and after GC around 78 MB(total),14 MB(JS)
Memory consumption graph
Hermes
Hermes was announced @ChainReactConf on 11th July 2019. It is an open-source JavaScript engine optimized for running React Native apps on Android.
App startup memory(MB) — 33 (total), 7 (JS) [↓ 65% (JS)]
After flat list loaded(MB) (870 items) -> 397(total), 110 (JS)
After GC (MB) ** -> 358 (total), 48 (JS)
**After adding records (app crashed after adding 50 records) -> 556(total),149(JS)
Garbage collection -> Yes, max memory reached 556 MB(total), 149 MB(JS) and after GC around 143 MB(total),48 MB(JS)
Memory consumption graph
Conclusion:
Based on the memory profiling graph, react-native-v8 is the winner closely followed by Hermes.
However, there is no one silver bullet for choosing JS engine in react-native. It all depends on one's use-case. It’s good that now react-native is giving options to the user to choose JS engines.
It is very important to measure your app’s performance against different JS engines and go with the one which suits your use-case the best.
