Jon Blower wrote:
Hi John,
It is possible that for various reasons, Java will
be "several times slower" than C code, so you'll have to decide if the
increase in productivity is worth it.
In what circumstances would Java-NetCDF be "several times slower" than
C? I've always found nj to be very close to our old C++ code in terms
of speed, and nj4 appears to be faster than nj2. (In a server
environment with a persistent, modern JVM - as you say, running a
one-off Java program has a big overhead in bootstrapping the JVM and
loading classes.)
I'd just like to know if there are any particular things I should look
out for that might badly affect performance.
Hi Jon, et al:
That was really just a CYA (CMA?) response, I believe java to be typically within 20% (plus or minus) of C/C++ code for long running programs. But not having seen Bill's code, I didnt want to claim anything i didn't know for sure. Improving performance is mostly the same as with any other language: get it working, profile it under a real load, find the bottlenecks, think (maybe hard), then optimize.
It is harder in Java because of the runtime loading and compiling, and garbage
collection, to understand what you are seeing in timing tests. Sometimes native
libraries can take advantage of hardware in a way that the JVMs cant. Thats the
tradeoff for platform-independence, but the JVMs do evolve (perhaps slowly) to
catch up.
The -server option seems to make a big improvement in JDK 1.6, so i recommend that. Ive
started to look at the new Java 7 NIO ("New IO") packages. Im hoping there
might be some real improvements there, since our apps tend to be IO bound.
John
