JNI performance benchmark.

2005년 3월 - 이글루스 내 블로그에서

 

Dawid Kurzyniec and Vaidy Sunderam. Efficient cooperation between Java and native codes -- JNI performance benchmark. In The 2001 International Conference on Parallel and Distributed Processing Techniques and Applications (PDPDA), Las Vegas, Nevada, USA, June25-28 2001.

각 JVM별로 JNI 성능은 얼마나 될까? 이런 궁금한 의문점없이 손쉽게 jni 코딩한다는 것은 상당히 위험스러울 수 있다. jvm 에 따라서 똑같은 코드라도 성능차이가 훨씬 나을 수 있는, 어떤 메소드의 형태냐에 따라 느리고, 빠르다는 것을 알수 있는 벤치마크 논문을 소개한다.

(1) non-virtual/ virtual invocation mode
(2) callback method invocation
(3) field access(private, virtual, static) / no,8 args
(4) arrays and strings
(5) exception
(6) 기타 jni 콜

이렇게 6가지 형태로 나누어서 벤치마크를 했는데, 전체적으로 볼 때, linux의 libm(IBM 1.3.0, jitc for Linux), windows의 wcli(Sun HotSpot Client 1.3.0-C for Win32), wibm(IBM 1.3.0, jitc for Win32) 등이 다른 vm보다 월등히 좋은 성능을 보여주었다.

이 논문에서는 다음과 같은 결론을 내리고 있다.

JIT-optimized 자바보다 다른 JVM은 느리다.
JNI에서 String을 리턴하면, 상당히 overhead가 존재한다.
작은 기능은 JNI에서 쓸 이유가 없다.
callback의 빈번함은 속도의 저하를 일으킨다.
jni 구현은 VM마다 다를수 있고, 새버젼이라서 무조건 빠로고, 성능이 좋다고 판단할 수 없다.
(lcls가 속도가 많이 늦은 이유는 복잡한 메모리 모델 알고리즘을 사용하기 때문이라고 한다.)

JNI가 항상 java보다 느릴 수도 있음을, 그리고, 어떤 메소드를 쓸 때는 상당히 조심스러운 부분이 있어야 함을 배웠다.
약간 아쉬운 부분이 있다면, 왜 jitc의 성능이 왜 좋은지, 어떻게 했기까닭에 좋을 수 밖에 없는지 약간의 비교, 분석이 있었으면 참 좋았겠다는 생각이 들었다.