[
https://issues.apache.org/jira/browse/IMAGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479190#comment-13479190
]
Gary Lucas edited comment on IMAGING-95 at 10/18/12 8:18 PM:
-------------------------------------------------------------
Well, I took another look at this, and it appears that my first tests weren't
accessing the ByteSourceInputStream, but were using the ByteSourceFile. So I
tried it again, following my own suggestion about using the
ApacheImagingSpeedAndMemoryTest application.
The results loading a 3600 by 1800 pixel image
using current version: 763.8 milliseconds
using your version: 176.4 milliseconds
So it looks like you're on the right track. Strictly as an aside,
I also tried testing with the ByteSourceFile and got a load time of
98 milliseconds.
{monospaced}
Using ByteSourceInputStream -------------------------------------
Processing file: BlueMarble.TIFF
image size: 3600 by 1800
time to load image -- memory
time ms avg ms -- used mb total mb
787.793 0.000 -- 63.075 92.191
859.587 0.000 -- 63.070 92.191
772.965 772.965 -- 62.894 84.473
651.912 712.439 -- 63.058 92.203
851.362 758.747 -- 63.061 92.203
818.632 773.718 -- 62.890 84.484
659.307 750.836 -- 63.058 92.203
911.201 777.563 -- 63.061 92.203
781.244 778.089 -- 62.890 84.484
663.920 763.818 -- 63.058 92.203
Processing file: BlueMarble.TIFF
image size: 3600 by 1800
time to load image -- memory
time ms avg ms -- used mb total mb
295.915 0.000 -- 63.073 92.188
193.905 0.000 -- 63.068 92.188
191.630 191.630 -- 62.892 84.473
214.639 203.134 -- 63.056 92.199
211.340 205.870 -- 63.059 92.199
182.537 200.036 -- 62.888 84.480
175.037 195.037 -- 63.056 92.199
166.024 190.201 -- 63.059 92.199
149.707 184.416 -- 62.888 84.480
176.374 183.411 -- 63.057 92.199
Using ByteSourceFile instead of ByteSourceInputStream ------------------
Processing file: BlueMarble.TIFF
image size: 3600 by 1800
time to load image -- memory
time ms avg ms -- used mb total mb
184.074 0.000 -- 26.417 40.285
90.738 0.000 -- 29.509 51.410
88.949 88.949 -- 30.485 47.816
104.790 96.869 -- 26.166 40.289
99.904 97.881 -- 26.084 40.289
98.153 97.949 -- 26.084 40.289
98.774 98.114 -- 26.084 40.289
98.111 98.113 -- 26.084 40.289
97.828 98.073 -- 26.084 40.289
98.742 98.156 -- 26.084 40.289
{monospaced}
was (Author: gwlucas):
Well, I took another look at this, and it appears that my first tests
weren't accessing the ByteSourceInputStream, but were using the ByteSourceFile.
So I tried it again, following my own suggestion about using the
ApacheImagingSpeedAndMemoryTest application.
The results loading a 3600 by 1800 pixel image
using current version: 763.8 milliseconds
using your version: 176.4 milliseconds
So it looks like you're on the right track. Strictly as an aside,
I also tried testing with the ByteSourceFile and got a load time of
98 milliseconds.
{monospaced}
Using ByteSourceInputStream -------------------------------------
Processing file: BlueMarble.TIFF
image size: 3600 by 1800
time to load image -- memory
time ms avg ms -- used mb total mb
787.793 0.000 -- 63.075 92.191
859.587 0.000 -- 63.070 92.191
772.965 772.965 -- 62.894 84.473
651.912 712.439 -- 63.058 92.203
851.362 758.747 -- 63.061 92.203
818.632 773.718 -- 62.890 84.484
659.307 750.836 -- 63.058 92.203
911.201 777.563 -- 63.061 92.203
781.244 778.089 -- 62.890 84.484
663.920 763.818 -- 63.058 92.203
Processing file: BlueMarble.TIFF
image size: 3600 by 1800
time to load image -- memory
time ms avg ms -- used mb total mb
295.915 0.000 -- 63.073 92.188
193.905 0.000 -- 63.068 92.188
191.630 191.630 -- 62.892 84.473
214.639 203.134 -- 63.056 92.199
211.340 205.870 -- 63.059 92.199
182.537 200.036 -- 62.888 84.480
175.037 195.037 -- 63.056 92.199
166.024 190.201 -- 63.059 92.199
149.707 184.416 -- 62.888 84.480
176.374 183.411 -- 63.057 92.199
Using ByteSourceFile instead of ByteSourceInputStream ------------------
Processing file: BlueMarble.TIFF
image size: 3600 by 1800
time to load image -- memory
time ms avg ms -- used mb total mb
184.074 0.000 -- 26.417 40.285
90.738 0.000 -- 29.509 51.410
88.949 88.949 -- 30.485 47.816
104.790 96.869 -- 26.166 40.289
99.904 97.881 -- 26.084 40.289
98.153 97.949 -- 26.084 40.289
98.774 98.114 -- 26.084 40.289
98.111 98.113 -- 26.084 40.289
97.828 98.073 -- 26.084 40.289
98.742 98.156 -- 26.084 40.289
> Some tiff processing takes very long
> ------------------------------------
>
> Key: IMAGING-95
> URL: https://issues.apache.org/jira/browse/IMAGING-95
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Affects Versions: 1.0
> Reporter: Amit Gupta
> Attachments: tiff_perf_fix2.patch
>
>
> org.apache.commons.imaging.formats.tiff.TiffReader.getTiffRawImageData(ByteSource,
> TiffDirectory) 226635 1
> org.apache.commons.imaging.common.bytesource.ByteSourceInputStream.getBlock(int,
> int) 226588 5616
> org.apache.commons.imaging.common.BinaryFileFunctions.skipBytes(InputStream,
> int) 226526 5616
> org.apache.commons.imaging.common.BinaryFileFunctions.skipBytes(InputStream,
> int, String) 226526 5616
> org.apache.commons.imaging.common.bytesource.ByteSourceInputStream$CacheReadingInputStream.read(byte[],
> int, int) 226526 188656860
> org.apache.commons.imaging.common.bytesource.ByteSourceInputStream$CacheBlock.getNext()
> 64581 188651244
> skip bytes is being called repeatedly again and again, last column is
> invocation count in one call tree. Second column is total number of time
> taken by that method in that call tree..
> and skip method is not overridden
> org.apache.commons.imaging.common.bytesource.ByteSourceInputStream.CacheReadingInputStream
> and default implementation of InputStream tries to use read method (which is
> overridden in CacheReadingInputStream) to skip.
> In case of a tiff, which has large number of strips, skip is repeatedly
> called and use of read is inefficient as it tried to do a System.arraycopy.
> array copy is not needed in case of skip operation, as the bytes were already
> read in block/cached, we can simply jump the pointer (block by block)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
