Hacker News new | ask | show | jobs
by cel1ne 3326 days ago
Assuming you don't do heavy work in the UI-loop: I find react-native's bridge memory-management on Android rather questionable: [0]

They make heavy use of structures in native memory for argument-passing between JavaScript and Java. Once again someone thought they could outperform the JVM with their C-skills. My critique was dismissed :-/

Even though I showed that giving up RN's native memory and just sending serialised Json-Strings on the Heap over the bridge is 50-100% faster (and doesn't interfere with GC, so it should have less lags as well): [1]

The image library they use, Fresco, does the same. There are many year-old bug-reports open regarding OutOfMemory-errors and crashes, and RN apps tend to get unstable with more images. My bug-report [2] was dismissed as well without proper explanation.

But: At least some guy or girl didn't have to give their custom code up for to the better JVM. scnr

I use Strings for arguments in production and it's faster, so maybe try that out. :)

[0] https://github.com/facebook/react-native/issues/8780

[1] https://github.com/facebook/react-native/issues/10504

[2] https://github.com/facebook/fresco/issues/1363

1 comments

While there is a vm of sorts on Android, there's no jvm. Is your comment about Android or the (traditional) jvm?
I did all the benchmarks on Android ART. It's not the JVM, but blocking GC is an inherent design problem of finalizers that can't be fixed on any VM.