On 16/07/2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>  I couldn't find a JIRA for compress so I'm posting it here.
>

Compress is currently in the Sandbox.

>  We had a bug report against Ant's ZipOutputStream that showed that the
>  class had a way worse performance compared to java.util.zip's cousin
>  when it was used to compress big files.  See
>  https://issues.apache.org/bugzilla/show_bug.cgi?id=45396
>
>  Attached to this report is a small test class that could easily be
>  adapted to the compress library.
>
>  It turns out that java.util.Deflater doesn't like to see big arrays
>  passed into its setInput method and the original reporter says
>  OpenJDK's code would split the input into 512 byte chunks.  While I
>  didn't verify the OpenJDK code I went looking into zlib and InfoZIP
>  and at least InfoZIP's zipup.c uses smaller chunks (between 2kB and
>  16kB) as well when compressing files.
>
>  The change I've committed
>  
> http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/zip/ZipOutputStream.java?r1=579278&r2=677272&pathrev=677272
>  sped up the test by a factor of 40 on my machine.
>
>  It won't have any effect on Ant since <zip> has always split up the
>  file's content before writing it to the archive, but it would affect
>  other direct users of our API - and would probably benefit the
>  compress component for just that reason as well.
>
>  Stefan
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to