进行JNI呼叫的定量开销是多少？

Question

仅基于性能,大约有多少"简单"的java行是进行JNI调用的等效性能？

或者尝试以更具体的方式表达问题,如果是简单的java操作,例如

someIntVar1 = someIntVar2 + someIntVar3;

给出了一个"CPU工作"索引1,那个JNI调用开销的典型(球场)"CPU工作"索引是什么？

此问题忽略了等待本机代码执行所花费的时间.在电话用语中,它严格来说是呼叫的"旗帜下降"部分,而不是"呼叫率".

提出这个问题的原因是有一个"经验法则",当你知道本地成本(来自直接测试)和给定操作的java成本时,知道何时打算尝试编写JNI调用.它可以帮助您快速避免编写JNI调用的麻烦,只是发现callout开销消耗了使用本机代码的任何好处.

编辑:

有些人对CPU,RAM等的变化感到困惑.这几乎与问题无关 - 我要求java代码行的相对成本.如果CPU和RAM很差,它们对java和JNI都很差,因此环境因素应该平衡.JVM版本也属于"无关"类别.

这个问题不是要求以纳秒为单位的绝对时间,而是以"简单java代码行"为单位的球场"工作努力".

Answer 1

快速分析器测试产量:

Java类:

public class Main {
    private static native int zero();

    private static int testNative() {
        return Main.zero();
    }

    private static int test() {
        return 0;
    }

    public static void main(String[] args) {
        testNative();
        test();
    }

    static {
         System.loadLibrary("foo");
    }
}

C库:

#include <jni.h>
#include "Main.h"

JNIEXPORT int JNICALL 
Java_Main_zero(JNIEnv *env, jobject obj)
{
    return 0;
}

结果:

系统细节:

java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-1)
OpenJDK Server VM (build 23.2-b09, mixed mode)
Linux visor 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 GNU/Linux

更新:x86(32/64位)和ARMv6的 Caliper微基准测试如下:

Java类:

public class Main extends SimpleBenchmark {
    private static native int zero();
    private Random random;
    private int[] primes;

    public int timeJniCall(int reps) {
        int r = 0;
        for (int i = 0; i < reps; i++) r += Main.zero();
        return r;
    }

    public int timeAddIntOperation(int reps) {
        int p = primes[random.nextInt(1) + 54];   // >= 257
        for (int i = 0; i < reps; i++) p += i;
        return p;
    }

    public long timeAddLongOperation(int reps) {
        long p = primes[random.nextInt(3) + 54];  // >= 257
        long inc = primes[random.nextInt(3) + 4]; // >= 11
        for (int i = 0; i < reps; i++) p += inc;
        return p;
    }

    @Override
    protected void setUp() throws Exception {
        random = new Random();
        primes = getPrimes(1000);
    }

    public static void main(String[] args) {
        Runner.main(Main.class, args);        
    }

    public static int[] getPrimes(int limit) {
        // returns array of primes under $limit, off-topic here
    }

    static {
        System.loadLibrary("foo");
    }
}

结果(x86/i7500/Hotspot/Linux):

Scenario{benchmark=JniCall} 11.34 ns; ?=0.02 ns @ 3 trials
Scenario{benchmark=AddIntOperation} 0.47 ns; ?=0.02 ns @ 10 trials
Scenario{benchmark=AddLongOperation} 0.92 ns; ?=0.02 ns @ 10 trials

       benchmark     ns linear runtime
         JniCall 11.335 ==============================
 AddIntOperation  0.466 =
AddLongOperation  0.921 ==

结果(amd64/phenom 960T/Hostspot/Linux):

Scenario{benchmark=JniCall} 6.66 ns; ?=0.22 ns @ 10 trials
Scenario{benchmark=AddIntOperation} 0.29 ns; ?=0.00 ns @ 3 trials
Scenario{benchmark=AddLongOperation} 0.26 ns; ?=0.00 ns @ 3 trials

   benchmark    ns linear runtime
         JniCall 6.657 ==============================
 AddIntOperation 0.291 =
AddLongOperation 0.259 =

结果(armv6/BCM2708/Zero/Linux):

Scenario{benchmark=JniCall} 678.59 ns; ?=1.44 ns @ 3 trials
Scenario{benchmark=AddIntOperation} 183.46 ns; ?=0.54 ns @ 3 trials
Scenario{benchmark=AddLongOperation} 199.36 ns; ?=0.65 ns @ 3 trials

   benchmark  ns linear runtime
         JniCall 679 ==============================
 AddIntOperation 183 ========
AddLongOperation 199 ========

总结一下,似乎JNI调用大致相当于典型(x86)硬件和Hotspot VM上的10-25个java操作.毫不奇怪,在优化程度较低的Zero VM下,结果完全不同(3-4个操作).

感谢@ Giovanni Azua和@ Marko Topolnik的参与和提示.

Answer 2

因此，我只是使用 Eclipse Mars IDE、JDK 1.8.0_74 和 VirtualVM 分析器 1.3.8 以及 Profile Startup 附加组件，在 64 位 Windows 8.1 上测试了对 C 的 JNI 调用的“延迟”。

设置：（两种方法）
SOMETHING() 传递参数，做东西，并返回参数
NOTHING() 传入相同的参数，对它们不做任何事情，并返回相同的参数。

（每个被称为270倍），
总运行时间的东西（）：6523ms
总运行时间为NOTHING（）：0.102ms

因此，在我的情况下，JNI 调用可以忽略不计。