5 ms·

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 g

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?

ruimagalhaes 9y ago
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.
htormey 9y ago
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 9y ago
  We are using SQLite. The performance bottleneck is not the database itself but conversion between the Java and JavaScript environments.
  - contingencies 9y ago
    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?
  - woah 9y ago
    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 9y ago
      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 9y ago
        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?
cel1ne 9y 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 https://github.com/facebook/react-native/issues/8780 [1] https://github.com/facebook/react-native/issues/10504 https://github.com/facebook/react-native/issues/10504 [2] https://github.com/facebook/fresco/issues/1363 https://github.com/facebook/fresco/issues/1363
- e12e 9y ago
  While there is a vm of sorts on Android, there's no jvm. Is your comment about Android or the (traditional) jvm?
  - cel1ne 9y ago
    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.
tootie 9y ago
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 9y ago
  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.

ruimagalhaes 9y ago

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.

htormey 9y ago

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 9y ago
We are using SQLite. The performance bottleneck is not the database itself but conversion between the Java and JavaScript environments.
- contingencies 9y ago
  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?
- woah 9y ago
  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 9y ago
    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 9y ago
      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?

cel1ne 9y 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 https://github.com/facebook/react-native/issues/8780 [1] https://github.com/facebook/react-native/issues/10504 https://github.com/facebook/react-native/issues/10504 [2] https://github.com/facebook/fresco/issues/1363 https://github.com/facebook/fresco/issues/1363

e12e 9y ago
While there is a vm of sorts on Android, there's no jvm. Is your comment about Android or the (traditional) jvm?
- cel1ne 9y ago
  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.

tootie 9y ago

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 9y ago
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.