   Java - C++ performance overhead
  I`m investigating using C++ for the main application and Java as a scripting language.  Ignore the whole static versus dynamic typing and learning curve arguments - I only want to talk about performance.Java is fast and C++ is fast but JNI (the interface between them) is notoriously slow.  My research with Google has come up with numbers like:*calls from Java to C++ are 2-3 times slower than Java to Java calls*calls from C++ to Java are 10-20 times slower than Java to Java callsBut all is not lost... some smart people are working on improving this situation.  For example there`s a paper called `Inlining Java Native Calls At Runtime` (link:  http://www.usenix.org/events/vee05/full_papers/p121-stepanian.pdf) that talks about ways these bad performance numbers can be overcome.  Given this paper was written 4 years ago I would have expected some of the Java implementations to have now reduced their native call overheads.  Given that the paper was cowritten by IBM employees and they tweaked the IBM Java compiler and JVM, I`m guessing that one or more of IBM JDKs might have these optimizations in them.  However, as far as I can tell, IBM licensing agreements on their JDKs don`t make them free to use for commercial purposes.This brings me to the point of my post.  I am wondering if anyone else is aware of any *recent* JVM comparisons where Java to C++ and C++ to Java calls have been profiled.  Or perhaps someone has practical experience along the lines of using Java as a scripting language from C++.  I am trying to find a free JVM that has a low overhead going both ways between Java and C++.   
  What are you trying to benefit from by using Java? JNI is not as bad as it sounds.;Quote:JNI is not as bad as it sounds.A similar search brought me to this topic.  Can you expound on this statement?  For instance, what would be a good use case JNI vs. a bad case?Best Regards!   ;  This is the kind of things I've read (from http://mindprod.com/jgloss/jni.html):Quote:A JNI call is very slow, in the order of .5 to 1.0 microseconds, the equivalent of pages of linear Java code to do a simple method call. You would think there would be a tiny generated machine code thunk to bridge between Java and C. Not so — at least in any JVM I know of, Java branches to some general purpose code that interpretively constructs the C parameters. This code is not highly optimised. It seems Sun wants to strongly discourage you from using native methods just for speed. This means you don’t want to hop back and forth between Java and C, but rather to go to C, and stay there a decently long time before returning. This means that you can’t use C to speed up short operations, only long ones, because of the overhead tacked on in getting to C wipes out any savings.Not just there, but in many places.  The paper I linked and other papers I've found have numbers in them to back up their claims.  However, none of the information I've been able to find is terribly recent and there have been optimizations going on to JNI.  Some JVMs handle it a lot faster than others.  I'm trying to find benchmarks to figure out which JVM to use.  The latest news I could really find was a Sun Java developer on this thread http://mail.openjdk.java.net/pipermail/discuss/2008-March/001118.html:Quote:   Some members of the Java2D team would incline to   respectfully disagree with the assessment that JNI is   "that" fast =)   Jim Graham wrote an extensive JNI benchmark (which tests method calls   with different types/number of arguments, Get/Set methods,   GetPACritical, etc), and ran it against multiple Java releases.   We have an internal page with the results. Unfortunately we don't   have the bandwidth to get the benchmark out.   The net result is that while the jni performance had improved   over the years (the amount of improvement varies   from platform to platform) it is still not satisfactory   in many areas. Our per primitive cost is still mostly   consists of jni overhead for small primitives (think   fillRect(1x1)).;  I've read these some of these articles and have come to the same conclusions.I am wondering if this thread isn't in the correct forum?  Perhaps this belongs in "General Programming"?First off, Java isn't what I would consider a scripting language, at least not in the traditional sense since it is run through the VM instead of being managed at the application level.  Perhaps I'm wrong, but I haven't seen Java used as a "pure" scripting language in games with the exception of Robocode.Second, the ideas that are being addressed in this thread are at a lot lower level than typical script questions since it addresses a number of subjects which scripting usually and can safely ignore.Would it be reasonable for a mod to move this to the "General Programming" (or something more suitable)?   ;  I think the original Vampire the masquerade game used Java as it's scripting language.The Unreal engine almost decided to use Java, but instead created UnrealScript.   ;  The hard part about ensuring JNI performance is that all the users need to have a minimum version of Java, such as 1.5.JNI performance shouldn't be that bad anymore, considering JOGL runs through JNI and from the examples, the 3D applications made have speeds comparable to the equivalent OpenGL stuff in C.Note though, JNI possibly isn't the slow part - the slow part is transferring data between native and Java memory - that should hurt more. This was one of the reasons IO suffered until they made NIO that uses native memory exclusively.   ;  Did you try looking into alternatives for JNI?I never did scripting with Java, but a quick google search for "JNI replacements" brought up the following posts:J/Invoke vs Native Chttp://www.jinvoke.com/node/88J/Invoke vs JNAhttp://www.jinvoke.com/node/98J/Invoke as an easy replacement for JNIhttp://j2eeblogs.blogspot.com/2007/09/jinvoke-easy-jni-replacement.htmlI couldn't find any actual benchmarks between J/Invoke and JNI. But the first link leads me to believe that it would be faster. While the third leads me to believe that it would be easier (This is, of course, a non-issue if you're already familiar with JNI).Besides you shouldn't do calls from C++ to Java unless you plan to use some sort of event handling system which requires it. I.E. Passing a pointer to a function from Java to C++, and then C++ calls it when the event is fired. When I script with lua, this is the only time C++ actually calls the lua code. Because I prefer to extend the C++ code, rather than embed scripts into it (This also makes your program more powerful and customizable).With something like J/Invoke or JNI, extend really seems the way to go. Using a language like Java as an over-glorified configuration file would rob you of all the power the language has to offer.Good luck.;  hi,i have used jni (by using jogl) and the diffrence in speed is the following :every call (with jni) to a c++ method is like 4-10 method invocations of java.Because most of my code was jogl commands (about 50%) the final speed difference between pure c++ and java was that c++ was 250%-300% faster.If i wanted i could transfer almost all data from java to c++ with only 1 method call and negate the jni cost. However that would look ungly (e.g a method with many parameters / require extra coding (i am lazy)).thanks.   