You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Dawid Weiss (JIRA)" <ji...@apache.org> on 2018/01/09 20:29:00 UTC

[jira] [Created] (COMPRESS-438) ZipFile should create a buffered input stream for decoders inside getInputStream(ZipArchiveEntry)

Dawid Weiss created COMPRESS-438:
------------------------------------

             Summary: ZipFile should create a buffered input stream for decoders inside getInputStream(ZipArchiveEntry)
                 Key: COMPRESS-438
                 URL: https://issues.apache.org/jira/browse/COMPRESS-438
             Project: Commons Compress
          Issue Type: Improvement
            Reporter: Dawid Weiss
            Priority: Minor


When decoders read from a raw underlying stream (such as a file channel), the performance can degrade an order of magnitude compared to the case when there's a simple buffer in between the physical data source and the codec. 

See COMPRESS-380 for an example of this.

The API of {{ZipFile}} is straightforward and tempting enough that blocks of code such as:
{code}
    try (ZipFile zfile = new ZipFile("/path/to/zip.zip")) { 
      Enumeration<ZipArchiveEntry> entries = zfile.getEntries();
      while (entries.hasMoreElements()) {
        ZipArchiveEntry e = entries.nextElement();

        try (InputStream is = zfile.getInputStream(e)) {
          // do something with is
        }
      }
    }
{code}

seem perfectly justified. The above code suffers from severe performance degradation compared to prebuffered input. I'll attach some examples.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)