[thedjinn]

I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?

[cel1ne]

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

[e12e]

While there is a vm of sorts on Android, there's no jvm. Is your comment about Android or the (traditional) jvm?

[cel1ne]

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.

[ruimagalhaes]

It doesn't defeat the purpose entirely in my opinion. Even if you write that core native code and use RN for the rest of the app, those elements will be potentially easier to ship and maintain.

[tootie]

You're running a local db of some sort? I'd assume you'd always want your app to be a thin client and just fetch data via REST or RPC.

[thedjinn]

Our app is used by people working in remote areas without mobile/wifi reception. Therefore we maintain a local copy of the user's state.

[htormey]

What database were you using and what bottlenecks did you run into? Curious as I have yet to work with dbs in React Native.

[thedjinn]

We are using SQLite. The performance bottleneck is not the database itself but conversion between the Java and JavaScript environments.

[woah]

Obviously almost every react native app out there is accessing a SQL db over the network, and they work fine. Are you seriously saying that it's slower to get data over the react native bridge than over the internet?

[thedjinn]

No, such a claim would be complete nonsense.

We are using a local database as a mirror for offline use, which is a key requirement. Profiling (a forgotten art nowadays) shows that most time spent during queries is in this bridge and not in the actual queries.

[htormey]

I know realm has a React Native library which I imagine you could use to access the db directly. Can you do something like that with SQLite? I.e access it without going through java/the bridge?

[contingencies]

What was the size of the result set?

Have you tried appending '... LIMIT <count> [OFFSET <skip>]' to constrain the per-query result set to a reasonable size?