[
https://issues.apache.org/jira/browse/COMPRESS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980703#comment-15980703
]
ASF GitHub Bot commented on COMPRESS-388:
-----------------------------------------
Github user kvr000 commented on the issue:
https://github.com/apache/commons-compress/pull/21
Update, improving few things:
- made the fields private again
- simplified to single read(long pos, ByteBuffer buf) method
- allocating the instance buffer only for single byte read which is rather
rare (so far it seems that only Bzip2 uses it for reading the header), all
other decompressors and even standard java core readers use internal cache.
- wrapping the byte array passed by parameters instead of creating
temporary ByteBuffer and copying the bytes
Performance improved in comparison to previous commit:
- 15%-20% for stored stream
- 1%-3% for deflated stream
> 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)
