Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 18 Oct 2012 17:08:03 +0000 (UTC)
From: "Gary Lucas (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <568301254.64544.1350580083617.JavaMail.jiratomcat@arcas>
In-Reply-To: <1332491254.47226.1350333063501.JavaMail.jiratomcat@arcas>
Subject: [jira] [Comment Edited] (IMAGING-95) Some tiff processing takes
 very long
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/IMAGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479142#comment-13479142 ] 

Gary Lucas edited comment on IMAGING-95 at 10/18/12 5:06 PM:
-------------------------------------------------------------

I'm not part of the Apache Commons Imaging project team, but I am interested in this issue...  Few people would welcome a speed enhancement for TIFF images with more enthusiasm than I :-)

I tried your patch with a couple of test files I have and didn't see much difference in measured processing time.  Unfortunately, I've got all sorts of security software running on my computer and it makes for a noisy test environment, so I can't be sure.   So I have a couple of questions:

a) Are there specific TIFF formats where you've observed an improvement?
b) Have you tried running before-and-after tests using the ApacheImagingSpeedAndMemoryTest.java application?

The ApacheImagingSpeedAndMemory.java class is in the Commons Imaging code distribution under the path src\test\java\org\apache\commons\imaging\examples   There are detailed instructions for using it in the comments inside the code.  It is designed to give reasonably unambiguous timing information about how long it takes to load an image (it is coded for TIFF images, but can be edited to process other formats).

That being said, I would encourage you to include test statistics and more specific details about your test procedures when posting about performance issues.  Speaking from personal experience, doing so does a lot to add credibility to your work (and who among us doesn't need more of that ?).
                
      was (Author: gwlucas):
    I'm not part of the Apache Commons Imaging project team, but I am interested in this issue...  Few people would welcome a speed enhancement for TIFF images with more enthusiasm than I :-)

I tried your patch with a couple of test files I have and didn't see much difference in measured processing time.  Unfortunately, I've got all sorts of security software running on my computer and it makes for a noisy test environment, so I can't be sure.   So I have a couple of questions:

a) Are there specific TIFF formats where you've observed an improvement?
b) Have you tried running before-and-after tests using the ApacheImagingSpeedAndMemoryTest.java application?

The ApacheImagingSpeedAndMemory.java class is in the Commons Imaging code distribution under the path src\test\java\org\apache\commons\imaging\examples   There are detailed instructions for using it in the comments inside the code.  It is designed to give reasonably unambiguous timing information about how long it takes to load an image (it is coded for TIFF images, but can be edited to process other formats).
                  
> 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