Understanding the performance of my FFI-based API

[Maurizio Cimadamore]

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
>