Understanding the performance of my FFI-based API

[Maurizio Cimadamore]

Also, zooming into the benchmark, something funny seems to be going on 
with "getKeySegment". This seems different from the "getKeyArr" 
counterpart, but also has a new issue: I believe that, in JNI, you just 
passed the Java array "as is" - but in Panama you can't (as the array is 
on-heap), so there is some double-copying involved there (e.g. you 
create an on-heap array, which then is moved off-heap).

If I'm not mistaken, this method is executed on every benchmark 
iteration, so the comparison doesn't just mesure the cost of the native 
call, but also the cost it takes to marshal data from Java heap to native.

For instance, the byte buffer versions ("keyBuf") seem to avoid this 
problem by copying the data directly off-heap (by using a direct 
buffer). I think the benchmark should use a native segment, and avoid 
the copy so that at least we avoid that source of noise in the numbers.

Cheers
Maurizio

On 09/03/2023 11:29, Maurizio Cimadamore wrote:
> Hi Alan,
> first of all, I'd like to thank you for taking the time to share your 
> experience and to write it all up in a document. Stuff like that is 
> very valuable to us, especially at this stage in the project.
>
> One quick suggestion when eyeballing your code: your method handles 
> are "static", but not "final". I suggest you try to sprinkle "final" 
> in, and see whether that does the trick. If not, we'd have to look 
> deeper.
>
> Cheers
> Maurizio
>
> On 09/03/2023 11:15, Alan Paxton wrote:
>> Hi,
>>
>> I hope this is an appropriate list for this question.
>>
>> I have been prototyping an FFI-based version of the RocksDB Java API, 
>> which is currently implemented in JNI. RocksDB is a C++ based 
>> key,value-store with a Java API layered on top. I have done some 
>> benchmarking of the FFI implementation, versus the JNI version and I 
>> find it performs consistently slightly slower than the current API.
>>
>> I would like to understand if this is to be expected, e.g. does FFI 
>> do more safety checking under the covers when calling a native method ?
>> Or is the performance likely to improve between the preview in Java 
>> 19 and release in Java 21 ?
>> If there are resources or suggestions that would help me dig into the 
>> performance I'd be very grateful to be pointed to them.
>>
>> For the use case I'm measuring, data is transferred in native memory 
>> originally allocated by RocksDB in C++ which I wrap as a 
>> MemorySegment; I do allocate native memory for the request structure.
>>
>> These are links to the PR and some documentation of the work:
>>
>> https://github.com/facebook/rocksdb/pull/11095
>> https://github.com/alanpaxton/rocksdb/blob/eb-1680-panama-ffi/java/JavaFFI.md 
>>
>>
>> Many thanks,
>> Alan Paxton
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230309/0a6370f0/attachment-0001.htm>