Comparing the performance of Panama with JNI, JNA, and JNR - based on Java 21

[Maurizio Cimadamore]

On 26/03/2023 14:17, Sebastian Stenzel wrote:
>> Am 26.03.2023 um 14:46 schrieb Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
>>
>> Forgot: another problem is that just offloading to external "strlen" will not respect the memory segment boundaries (e.g. the underlying strlen will keep going even past the spatial boundaries of the memory segment).
> How about using strnlen? At least for native segments?
>
> Improving string conversion efficiency would make a huge difference in my FUSE bindings, where virtually every call contains a file path.

That could be more useful, yes (was thinking along similar lines).

That said, note that if performance of string conversion is really 
critical, you can roll your own C to Java String conversion easily - 
just link to "strlen" or "strnlen" - call that on the native segment (to 
find string length). Then do a bulk copy (using MemorySegment::copy) to 
a byte[] with the found length. Then create a String instance from the 
new byte[]. This can be done once in a static helper method, which can 
then be reused across your application.

(not saying that JDK shouldn't try to do better - just saying that you 
don't have to be bound by the performance of whatever strlen algo the 
JDK provides).

Also note, doing some benchmark on my local machine, I noted 
improvements with native `strlen` only for strings bigger than a certain 
size (break even in my case was 20 chars). Which might or might not be 
the common case in your FUSE bindings.

Maurizio