Gary Lucas created SANSELAN-78:
----------------------------------
Summary: Improve speed of random-access-file handling for TIFF
format, potentially others
Key: SANSELAN-78
URL: https://issues.apache.org/jira/browse/SANSELAN-78
Project: Commons Sanselan
Issue Type: Improvement
Components: Format: TIFF
Reporter: Gary Lucas
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.
{code}
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.
{code}
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
