JNI benchmarks

[ivnsch]

Some findings:

1. JNI calls are at least (no parameters and return values) 3-5x slower than non JNI calls.
2. Sending and returning an int primitive has about the same performance as sending / returning nothing.
3. Converting Java strings to Rust strings (parameters) or returning Java strings from Rust is expensive. A call that returns a string is ~30x slower than a call that returns nothing.
4. Passing or returning classes (even if only with an integer primitive) is very expensive. Passing is about 4x slower than sending a string. Returning is ~16x slower than returning a string. Note: "passing" means processing the fields, such that they're usable in Rust, and "returning", constructing an object that can be used in Kotlin. It would be interesting to compare this with point 3 using a JSON based api.

A general consequence of this would be to prefer to return int-only codes (instead of a class with code + optional message), at least for performance critical calls. Otherwise, it should be evaluated on per-case basis.

The documented benchmarks were done with a million iterations.

I expect iOS to be much quicker, as it shouldn't do any serialization / deserialization. Without the JSON based api, of course.

[duskoo]

I wonder if Rust compiler optimizations are impacting test cases. There is a short discussion of the problem here: https://doc.rust-lang.org/1.2.0/book/benchmark-tests.html

[ivnsch]

That's a good point. Rust here is compiled in debug mode, so there are probably no optimizations. The unused variables in e.g. sendCreateStringForBenchmarks and sendClassForBenchmarks did affect significantly the benchmark, which backs it too. I doubt that other than this, using release mode will affect the JNI performance, but we should try it out.