[ https://issues.apache.org/jira/browse/COMPRESS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980452#comment-15980452 ]
ASF GitHub Bot commented on COMPRESS-388: ----------------------------------------- Github user sebbASF commented on a diff in the pull request: https://github.com/apache/commons-compress/pull/21#discussion_r112838358 --- 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 -- Do these really need to be protected rather than private or package-protected? > 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)