NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
netcdf-java
archives: