The FFI overhead in nodejs is significant. We have a project where a while back, after profiling, the majority of the CPU time was spent in a couple of small hotspots doing parsing and object construction in Nodejs.
I broke those out into a Rust library that was >100x faster (IIRC) in synthetic benchmarks with the same complexity. Plugging it in with FFI into the Nodejs app and it actually performed slightly worse due to FFI overhead and translation.
So for large documents; could be worth it. For lots of small objects; probably not. You'd have to try on real-world data for your use-case to know.
> I broke those out into a Rust library that was >100x faster (IIRC) in synthetic benchmarks with the same complexity. Plugging it in with FFI into the Nodejs app and it actually performed slightly worse due to FFI overhead and translation.
This is interesting. Have you tried to optimize for reducing the overhead? I can imagine that this can be hard/complex and require a refactoring of the consumer in some scenarios.
I broke those out into a Rust library that was >100x faster (IIRC) in synthetic benchmarks with the same complexity. Plugging it in with FFI into the Nodejs app and it actually performed slightly worse due to FFI overhead and translation.
So for large documents; could be worth it. For lots of small objects; probably not. You'd have to try on real-world data for your use-case to know.
Also https://github.com/luizperes/simdjson_nodejs/issues/5