[
https://issues.apache.org/jira/browse/COMPRESS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980457#comment-15980457
]
ASF GitHub Bot commented on COMPRESS-388:
-----------------------------------------
Github user kvr000 commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838711
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -1081,16 +1082,26 @@ private boolean startsWithLocalFileHeader() throws
IOException {
}
/**
+ * Creates new BoundedInputStream, according to implementation of
+ * underlying archive channel.
+ */
+ private BoundedInputStream createBoundedInputStream(long start, long
remaining) {
+ return archive instanceof FileChannel ?
+ new BoundedFileChannelInputStream(start, remaining) :
+ new BoundedInputStream(start, remaining);
+ }
+
+ /**
* InputStream that delegates requests to the underlying
* SeekableByteChannel, making sure that only bytes from a certain
* range can be read.
*/
private class BoundedInputStream extends InputStream {
- private static final int MAX_BUF_LEN = 8192;
- private final ByteBuffer buffer;
- private long remaining;
- private long loc;
- private boolean addDummyByte = false;
+ protected static final int MAX_BUF_LEN = 8192;
+ protected final ByteBuffer buffer;
+ protected long remaining;
+ protected long loc;
+ protected boolean addDummyByte = false;
--- End diff --
They can be package protected too, it's in private class anyway. The fields
are accessed by the FileChannel specialization so private won't suffice.
> Improve concurrent reads from ZipFile
> -------------------------------------
>
> Key: COMPRESS-388
> URL: https://issues.apache.org/jira/browse/COMPRESS-388
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
> Affects Versions: 1.13
> Environment: Any
> Reporter: Zbynek Vyskovsky
> Labels: patch, performance
> Fix For: 1.14
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Concurrent reads on the ZipFile archive is terribly slow on multiprocessor
> systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples
> for example.
> The cause is the use of synchronized blocks to access the underlying file
> channel. This may be required for generic SeekableByteChannel but most
> commonly there is FileChannel implementation which supports lock-free reading
> from any position (i.e. using pread/pwrite system calls or their equivalent).
> With the fix the performance is about 10 times faster (on 4 CPU system, with
> more processor the difference should grow significantly).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
