Hi Stefan, compress is a component of the commons-sandbox project: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310491&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12311183
@Torsten: i will prepare a patch for the redesign branch. On Wed, Jul 16, 2008 at 3:20 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Hi all, > > I couldn't find a JIRA for compress so I'm posting it here. > > 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] > >
