Performance LuaJIT for Java Bridge

[joko-prasetyo]

Hi, thank you for creating this awesome library, I’m currently benchmarking LuaJava against LuaJ/LuaJIT in Android platform mostly as Java Bridge to call Java object and I’m seeing mixed performance results depending on the use case. For pure/native Lua calculations, LuaJava (with LuaJIT) performs significantly better—around a 90% improvement compared to LuaJ, as shown in the attached benchmark. However, when I use LuaJava to frequently call Java methods, the performance becomes noticeably worse than LuaJ. This seems counterintuitive given the large speedup in native computation. Is this slowdown expected due to JNI/Java bridge overhead.
? Are there recommended patterns or optimizations to improve LuaJava performance when interacting heavily with Java/Android services?

This is an example calling a fibonacci sequence, LuaJIT performs better

Besides that, I made a java method that have access to Android's internal API by using LuaJ took 450+ calls/sec when using LuaJ, but when I use LuaJIT it only gets 235+ calls/secs

[gudzpoz]

Yep, this is very typical LuaJIT behaviour. I remember there are some great articles (or mailing list entries) talking about this. But here is the best that I can find in a few minutes: Callback performance - LuaJIT.

So, yes, LuaJIT is most fast when your code is mostly in Lua (or Lua + LuaJIT FFI). When Lua/C (or Lua/C/Java) API is heavily used, LuaJIT basically can't do anything because it can't optimize across the boundries. However, for LuaJ, with all the code in Java, JVM can optimze things across the boundries, potentially made the API calls cheaper.

This repository has some benchmarks on this:

Benchmark                                        (lua)   Mode  Cnt       Score        Error  Units
MethodCallBenchmark.benchmarkModuleMethodCall  Lua 5.4  thrpt    3  511618.935 ± 283665.340  ops/s
MethodCallBenchmark.benchmarkModuleMethodCall   LuaJIT  thrpt    3  734932.821 ±  59623.667  ops/s
MethodCallBenchmark.benchmarkModuleMethodCall     LuaJ  thrpt    3  735017.542 ± 131263.665  ops/s
MethodCallBenchmark.benchmarkObjectMethodCall  Lua 5.4  thrpt    3  435984.452 ±  11562.229  ops/s
MethodCallBenchmark.benchmarkObjectMethodCall   LuaJIT  thrpt    3  596236.301 ±  35344.869  ops/s
MethodCallBenchmark.benchmarkObjectMethodCall     LuaJ  thrpt    3  565046.642 ± 313067.169  ops/s
SimpleBenchmark.benchmarkBinaryTrees           Lua 5.4  thrpt    3    2628.202 ±    134.846  ops/s
SimpleBenchmark.benchmarkBinaryTrees            LuaJIT  thrpt    3    4584.988 ±    340.895  ops/s
SimpleBenchmark.benchmarkBinaryTrees              LuaJ  thrpt    3     872.999 ±     15.044  ops/s

benchmarkBinaryTrees is the "mostly Lua code" case, where LuaJIT shines. benchmarkModuleMethodCall/benchmarkObjectMethodCall is the "mostly Lua/C (or Lua/Java) interfacing" case, where LuaJIT isn't as fast.

Android uses different JVM and can contain different optimizations though, and I can't really reason about it just looking at the numbers.

[joko-prasetyo]

Hi thank you for the reply, this is really helpful for my research, where do I can find the code of this benchmark ?

[gudzpoz]

They are at https://github.com/gudzpoz/luajava/tree/main/example/src/jmh

[joko-prasetyo]

thank you so much!

[gudzpoz]

You are welcome. :-) By the way, I modified the benchmarks a bit and added a page on the documentation site with a bit more explanations.