I profiled our Grib code (2.2.18) and found a bottleneck in some of the
low-level routines such as Grib1BinaryDataSection.bits2UInt(),
ucar.unidata.io.RandomAccessFile.read(), and, to a lesser degree, in
ucar.grib.GribNumbers.float4().
Has the UCar team ever thought of moving to Java NIO? I rewrote the
ucar.grib.GribNumbers.float4() method in NIO and got 10 fold performance
boost. I will post the new float4() if anyone is interested.
As far as RandomAccessFile.read(), the reason our program was spending
so much time in it was because of a multiplier inside the
Grib1BinaryDataSection constructor. So 2,558 calls to the
Grib1BinaryDataSection constructor resulted in 273,175,727 calls to
RandomAccessFile.read()! Is there anything I can do about that?
Increase the defaultBufferSize size? It looks as if we have it set to
8K, but I was thinking of increasing that substantially. Can I do this
without a recompile?
Frederick Thurber
GDIT
Middletown, RI
