<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Also, zooming into the benchmark, something funny seems to be
going on with "<span class="pl-en">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).</span></p>
<p><span class="pl-en">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.</span></p>
<p><span class="pl-en">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.</span></p>
<p><span class="pl-en">Cheers<br>
Maurizio<br>
</span></p>
<div class="moz-cite-prefix">On 09/03/2023 11:29, Maurizio
Cimadamore wrote:<br>
</div>
<blockquote type="cite" cite="mid:b396bdb7-8ad4-76ca-2066-a94303974232@oracle.com">Hi
Alan,
<br>
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.
<br>
<br>
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.
<br>
<br>
Cheers
<br>
Maurizio
<br>
<br>
On 09/03/2023 11:15, Alan Paxton wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I hope this is an appropriate list for this question.
<br>
<br>
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.
<br>
<br>
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 ?
<br>
Or is the performance likely to improve between the preview in
Java 19 and release in Java 21 ?
<br>
If there are resources or suggestions that would help me dig
into the performance I'd be very grateful to be pointed to them.
<br>
<br>
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.
<br>
<br>
These are links to the PR and some documentation of the work:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/facebook/rocksdb/pull/11095">https://github.com/facebook/rocksdb/pull/11095</a>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/alanpaxton/rocksdb/blob/eb-1680-panama-ffi/java/JavaFFI.md">https://github.com/alanpaxton/rocksdb/blob/eb-1680-panama-ffi/java/JavaFFI.md</a>
<br>
<br>
Many thanks,
<br>
Alan Paxton
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>