<br>You can look at the BerkeleyDB's JNI wrapper edition(not Java Edition),
it's almost as fast as its c edition from my experience. I use both of
them in production.<br><div class="gmail_quote">On Fri, Mar 21, 2008 at 5:25 AM, Clemens Eisserer <<a href="mailto:linuxhippy@gmail.com">linuxhippy@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
I did some benchmarks to evaluate JNI-call-per-operation vs.<br>
Command-batch-buffer performance for a design where low per-primitive<br>
overhead is important.<br>
<br>
I was totally impressed about the low overhead JNI has in modern<br>
SUN-JVMs. On my Core2Duo-2ghz it took only 35cycles to call a native<br>
method with 4 jint parameters and count an int-loop-counter up, 58mio<br>
times per second. Making the methods synchronized however time went up<br>
to 100 cycles per call.<br>
<br>
Has JNI really become that fast, or is it likely that I have hit a<br>
microbenchmark trap?<br>
I thought JDK6 has BiasedLocking (I only tested single threaded), why<br>
is synchronization so expensive in this case? (my call-graph is<br>
benchmark-loop -> (synchronized) accessor-method -> native-method).<br>
<br>
Thanks, lg Clemens<br>
</blockquote></div><br><br clear="all"><br>-- <br>--<br>Yueyu Lin