Java version 25%

Hey I was looking more into the Java test and I found your comment of the added 25%. You should remove that and just do a + b inline because you are already paying the price of jumping from Java to native land so it makes no sense to add yet another indirection that is not needed. I would like to see what the best possible is.

[dyu]

@alexhultman

diff --git a/jhello/jhello_Hello.c b/jhello/jhello_Hello.c
index decadf9..cc4b868 100644
--- a/jhello/jhello_Hello.c
+++ b/jhello/jhello_Hello.c
@@ -18,8 +18,8 @@ JNIEXPORT jint JNICALL Java_jhello_Hello_plus
 JNIEXPORT jint JNICALL Java_jhello_Hello_plusone
   (JNIEnv *env, jclass clazz, jint x)
 {
-    return plusone(x);
-    //return x + 1;
+    //return plusone(x);
+    return x + 1;
 }
 
 JNIEXPORT jlong JNICALL Java_jhello_Hello_current_1timestamp

results

/usr/lib/jvm/java-7-oracle/bin/java -cp . jhello.Hello 500000000
3861
/usr/lib/jvm/java-7-oracle/bin/java -cp . jhello.Hello 500000000
3857

So it is actually only 15% difference instead of 25%

[pete23]

Although I’m a JVM fan in general, my view is that the original code seems a fairer comparison for the problem of calling an existing C function, rather than the problem of calling to native to get something done.

I have too many shells lying around of JNI typed and named wrappers - whether lovingly maintained or autogenerated - to let Java get a free pass over what’s an essential piece of the FFI machinery.

The overhead reduces the more work you do C-side (but so do your marshalling costs as well).

I don't agree. I think the test should focus on the best case scenario and that C should be 0 since you can just inline. The real difference that you really want to benchmark is whether the language in question has ridiculous calling costs such as Golang or JavaScript, or if it has reasonable cost.