Uploaded image for project: 'Commons Imaging'
  1. Commons Imaging
  2. IMAGING-63

Improve speed of random-access-file handling for TIFF format, potentially others

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Later
    • None
    • None
    • Format: TIFF
    • None

    Description

      Large TIFF files can be organized into chunks (either strips or tiles) so that the image can be read a piece-at-a-time. In the Apache Imaging implementation, each time one of these pieces is read, the TiffReader uses the getBlock() method of the ByteSourceFile class. This class opens the file using the Java RandomAccessFile class, seeks to the position of the data in the file, reads its content, and closes the file. Although this operation can be performed several times and thus entails a lot of redundant file opens and reads, the file cache performance on modern computers is truly amazing and for files of less than 5 megabytes, it often doesn't make a difference. On larger files, however, it can be significant.

      This Tracker Item proposes to modify the ByteSourceFile class so that an access routine can optionally hold the file open between getBlock() method calls. It will accomplish this by adding a new method called .setPersistent(boolean). By default, persistence will be set to false and the ByteSourceFile class will continue to work just as it always has (existing code will not be affected). If persistence is set to true, the RandomAccessFile will be held open.

      To get some sense of the performance difference, I ran several tests. For the sample "ron and andy.tif" file provided with the Apache Imaging package, which is under 5 megabytes, the change made little difference. However, when I tested with a larger files, such as the Apache Imaging sample 2560-by-1920 pixel PICT2833.TIF file (a blurry picture of a pretty girl), and a 2500-by-2500 pixel file I downloaded from the US Geological Survey (USGS), I saw notable differences.

      I also tested on a fast local disk (my PC) and on a network disk. Not surprisingly, the network disk showed the biggest change (in order to keep the test environment clean, I ran the network test early in the morning when the network was lightly used).

      As you can see in the tests below on the local disk the savings is modest even for the largest file. However, when dealing with a network file system, the change becomes significant.

      ron and andy.tif   1500-by-1125   4.8 MB       
          local  original:     25.9 ms.   
          local  modified:     24.8 ms.
          network original:   122.7 ms.
          network modified:   117.6 ms.
      
      PICT2833.TIF   2560-by-1920  14.1 MB
          local  original:     77.7 ms.   
          local  modified:     61.7 ms.
          network original:   774.1 ms.
          network modified:   463.8 ms.
      
      USGS1   2500-by-2500   18.8 MB
          local  original:    192.3 ms.   
          local  modified:     94.5 ms.
          network original:  3992.8 ms.
          network modified:  1807.1 ms.
      
      USGS2  10000-by-10000  286 MB
          local  original:   1930.5 ms.   
          local  modified:   1344.5 ms.
          network original: 26627.6 ms.
          network modified: 13402.1 ms.
      
      

      One consequence of this change is that if persistence is set to true, the file will be held open until the ByteSourceFile goes out-of-scope and is garbage collected. So this change will also make sure that the TiffReader sets the persistence back to false when it is done reading the file in order to expedite the release of file resources.

      Attachments

        Activity

          People

            Unassigned Unassigned
            gwlucas Gary Lucas
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: