Comparing the performance of Panama with JNI, JNA, and JNR - based on Java 21
Glavo
zjx001202 at gmail.com
Mon Mar 27 14:18:23 UTC 2023
Another idea related to usability and performance: Can Panama provide a
thread-local "native stack" to help users allocate local variables?
I have heard from others that LWJGL is using this technology. I also tried
to implement it:
https://github.com/Glavo/java-ffi-benchmark/blob/main/src/main/java/benchmark/experimental/NativeStack.java
I ran benchmarks where allocating a small number of local variables was
thirty times more efficient than using a confined arena.
If Panama can provide such a class, it will be more convenient and faster
for users to assign temporary variables.
Glavo
On Sat, Mar 25, 2023 at 3:07 AM Glavo <zjx001202 at gmail.com> wrote:
> I have run a series of benchmarks of Panama, JNI, JNA, and JNR based on
> the latest JDK. Here is its GitHub repository:
>
> https://github.com/Glavo/java-ffi-benchmark
>
> Here I tested the performance of no-ops, accessing structs, string
> conversions, and callbacks, respectively. I also tried the new isTrivial
> linker option.
> I summarized the results in README and charted them.
>
> In this email, in addition to sharing the above results, I would also like
> to talk about several issues I have encountered
>
> 1. MemorySegment.getUtf8String is unexpectedly slow
>
> Panama is much faster than JNA in most cases, but the operation of
> converting C strings to Java strings is an exception.
> I checked the source code of JNA and Panama, and the suspicious difference
> is that JNA uses strlen from the C standard library, while Panama uses Java
> loops.
> Perhaps this method can be optimized.
>
>
> 2. StructLayout must manually specify all padding
>
> Can we provide a convenient method for automatically padding between
> fields based on alignment?
> The current structLayout method is annoying for situations where you need
> to manually simulate the layout of a C struct.
>
>
> Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230327/b2cd5811/attachment.htm>
More information about the panama-dev
mailing list