[Question] Difference to react-native-sqlite-storage

[HenrikZabel]

What are the differences between this and the react-native-sqlite-storage package?
I saw that react-native-sqlite-storage hasn't been updated for a while but are there any
a) security
b) performance
c) etc.
differences that are important?

[ospfranco]

Most of the stuff you seek is in the README, the biggest differences happened in steps

react-native-sqlite-storage → react-native-quick-sqlite = moved to JSI, basically the same code but just a major speed bump

react-native-quick-sqlite → op-sqlite = polished a lot of smaller aspects, moved to HostObjects for increased performance, added on additional APIs, polished the code, fixed bugs, etc.

[HenrikZabel]

Thank you. Maybe this could be added to the top of the README. I think this may be interesting to others too.

[francescotescari]

@ospfranco What is the benefit of HostObjects?
The claim is "increased performance", but do we have numbers supporting this statement? IIUC we are basically avoiding the conversion from native world to JSI objects when returning the rows, but we pay that cost every time we access a property on the object, right? So measuring the performance to return the query result is a bit misleading if accessing the result is then slower, or requires a shallow_clone to do basic operations 🤔
In our app we end up JSON-encoding the rows we get out of the DB, and to our surprise the performance of that operation (JSON.stringify(results)) decreased noticeably with op-sqlite compared to react-native-sqlite-storage. We are wondering whether moving back from HostObjects to plain JS objects (created eagerly with JSI) could improve the overall throughput of our app.

Bonus: isn't it possible that by creating new jsi::Values on-demand when a HostObject property is retrieve we cause more GCs compared to hold the properties directly in a JS object?

Thanks for your amazing job 🙏

[ospfranco]

sqlite-storage does not use the JSI (or at least it wasn't when I created react-native-quick-sqlite). The jump to JSI already brought a huge performance boost compared to old JSON bridge libraries.

You are right, the cost is shifted to property access, the idea is to offload as much of the work to sqlite itself instead of paying for slow JS object creation. It might not fit the use case of your app, but in apps where only a few items are displayed at the time it is well worth the trade off.

I don't know why would you stringify the results, that's exactly where you will hit the slow path of host objects, because op-sqlite is focused on the most common use-case and running large native computations that's the trade-off I chose and I will not go back to creating all the objects eagerly.

You have two options, use another library, both react-native-quick-sqlite (maintained by margelo) or expo-sqlite use the JSI and eagerly create the JS objects, you can see with the results in the documentation how much you would pay. There is also the executeRawAsync function (check the docs) that does not create objects but return the data in a raw array, this will be faster than both quick-sqlite and expo-sqlite while returning all the data in JS scalars in one go, however they will not be wrapped in objects.

P.D. you should also compile your app in release mode (all C++ optimizations) before doing any benchmarking, both the bindings and sqlite code get a lot faster.