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)