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

• To: <netcdf-java@xxxxxxxxxxxxxxxx>
• Subject: [netcdf-java] Grib1Data and RandomAccessFile performance questions and Java NIO
• From: "Thurber, Fred" <Fred.Thurber@xxxxxxxx>
• Date: Thu, 21 Feb 2008 17:39:44 -0500

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

 

• Follow-Ups:
  • Re: [netcdf-java] Grib1Data and RandomAccessFile performance questions and Java NIO
    • From: John Caron