[netcdf-java] Grib1Data and RandomAccessFile performance questions and Java NIO

[Thurber, Fred]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.unidata.ucar.edu/mailing_lists/archives/netcdf-java/attachments/20080221/3edb5566/attachment.html