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

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

 

  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: