Memory usage for new modules made with JSI/Turbo modules #97
-
|
Hi everyone! I made a module a while back for hashing data using a pure Cpp implementation, and recently rewrote it in using expo modules with expo's new Module's API so i could use the code in the native platforms. One question that came up from another developer was how many copies of this data is there in RAM, which i thought for while but came up blank as i have no idea how JSI and Turbomodules handle the data passing. There will be one copy in JS, because that is the host platform, but what about the rest of the languages? When i create a cpp module and add it to the runtime, is it reading the JS memory space? What about when i use Turbomodules and end up in Java/Kotlin and Objective-C/Swift land? I would love to hear what you guys know. I feel like this might impact a lot of things regarding how i will make modules moving forward Edit: Thanks to @Kudo for the correction. Expo's modules API tries to use whatever it can based on the environment, and is indeed not Turbomodules |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
from my personal comment, pure c++ upon jsi is in theoretically faster than turbomodules. it could cost some overhead from language interoperability, e.g. passing data through jni on android comes with some cost. however, in real case it has other factors like the performance between apple CryptoKit and c++ hash library, if CryptoKit has some hardware optimization like SIMD support. if your data is large, you could consider using ArrayBuffer. expo module api (which is not turbomodule) would have ArrayBuffer and TypedArray support in the next release. |
Beta Was this translation helpful? Give feedback.
-
|
Do you know any benchmark, which would compare pure JSI vs turbomodules ? I am kinda interested in that. |
Beta Was this translation helpful? Give feedback.
from my personal comment, pure c++ upon jsi is in theoretically faster than turbomodules. it could cost some overhead from language interoperability, e.g. passing data through jni on android comes with some cost. however, in real case it has other factors like the performance between apple CryptoKit and c++ hash library, if CryptoKit has some hardware optimization like SIMD support.
if your data is large, you could consider using ArrayBuffer. expo module api (which is not turbomodule) would have ArrayBuffer and TypedArray support in the next release.