[
https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748846#comment-17748846
]
Gary Lucas commented on IMAGING-356:
------------------------------------
In follow up to my 17 July post, I made several attempts to expedite processing
by making code changes. None of them represented a significant improvement
and several "obvious improvements" actually degraded performance. My thought
is that any effective optimizations are already covered by Java's impressive
JIT compiler and optimizer. TIFF files store their data in blocks (strips or
tiles), but even changing the code to operate on block-oriented structures did
not help. My guess is that the more complicated code just got in the way of
Java's in-lining and other optimizations. Also, I think alternate data
structures might have interfered with the allocation of L2/L3 fast cache
memory, though this is an area in which I do not have a lot of experience.
I'm willing to abide by the consensus of the community here.... But If I had a
vote on this one, I'd like to get rid of the Math.addExtact and
Math.multipleExact methods since I think that these are just overcautious
coding practices. For one thing, the conditions they handle will never happen
(if something. corrupted the source image file, the Imaging code will fail long
before it tries to store pixel values in a memory). And for another, even if
the runtime processes made it into that function, the strict math doesn't
correct a problem. It just throws a different exception that the native code
would do. In fact, I think a case could be made for getting rid of the check
on the index value and going with the bare-bones implementation. In that case,
the worst thing that would happen is that the code would throw an
ArrayIndexOutOfBounds exception rather than the IllegalArgumentException or
ArithmeticException.
And just FYI... The fastest test results I got were with the bare bones
expression shown below. I think that by avoiding computing the index in a
separate variable, Java can optimize the statement slightly better than
otherwise.
data[ y * width + x] = argb;
> TIFF reading extremely slow in version 1.0-SNAPSHOT
> ---------------------------------------------------
>
> Key: IMAGING-356
> URL: https://issues.apache.org/jira/browse/IMAGING-356
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Affects Versions: 1.0
> Reporter: Gary Lucas
> Priority: Major
> Attachments: image-2023-07-04-08-52-36-535.png
>
>
> I am using the latest code from github (1.0-SNAPSHOT downloaded from github
> of June 2023) to read a 300 megabyte TIFF file. Version 1.0-alpha3 required
> 673 milliseconds to read that file. The new code requires upward of 15
> minutes. Clearly something got broken since the last release.
> The TIFF file is a 10000x10000 pixel 4 byte image format organized in strips.
> The bottleneck appears to occur in the TiffReader getTiffRawImageData method
> which reads raw data from the file in preparation of creating a BufferedImage
> object.
> I suspect that there may be a general slowness of file access. In debugging,
> even reading the initial metadata (22 TIFF tags) took a couple of seconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
