I make a DLL-Java communication correspondingly this post. My compilation configuration you can see there:
g++ -IC:\Users\RZ\Downloads\eigen-eigen-3.0.3\eigen-eigen-3.0.3 -IC:\Program Files\Java\jdk1.7.0\include\win32 -IC:\Program Files\Java\jdk1.7.0\include -O3 -msse -msse2 -mmmx -Wall -shared -c -o Vector3DImp.o ..\Vector3DImp.cpp
..\Vector3DImp.cpp:5:0: warning: "JNICALL" redefined
C:\Program Files\Java\jdk1.7.0\include\win32/jni_md.h:31:0: note: this is the location of the previous definition
g++ -Wl,--kill-at -shared -LC:\Program Files\Java\jdk1.7.0\lib -o Eigen.dll Vector3DImp.o
And then I write the same on Java. And launch a few tests with vector multiplication and vector addition: the result is:
Pure java 39 -38 ms
JNI Java 52 -50ms
Then I code the same test on C++ using the same code in DLL.
Result:
22 – 18 ms
Yeah the test strategy make seem rough, but the common result is sustainable.
Is there my fault or it is JNI drawback (I’m not good at it).
Note:
The main question is: Is it real the DLL use in Java is so hard (the performance reduces by 2.5 times). Why it is?
UPDATE:
At the request, there is source of test.
Sorry for mess there, it was made for my own need in short time.
My system configuration:
Windows 7 x32, Core 2 Duo.
Both Java and C++ projects were built in Eclipse IDEs with MingW Compiler for C++. For C++ vector calculation Eigen library was used. Also, I tried JBlas library, in the end of Java test it was awful, I don’t know why. Even with 3 multiplication operation (opposite 6 multiplication in cross product) the result was creepy. Look yourself.
There are several factors that negatively impact the speed with JNI
Data conversion between DLL and JVM. Your native DLL is little endian while JVM is a big endian so conversions are always performed. Sorry bu here is nothing left for improvement.
The passing of JNIEnv is quite time consuming
There are alternatives to JNI as JNA or CNI but do not expect massive improvements as the basic problem of passing data still remains. The major optimization here is to reduce either the number the calls to the native library or to pack parameters in a format that is friendly to both worlds.