[
https://issues.apache.org/jira/browse/COMPRESS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980284#comment-15980284
]
ASF GitHub Bot commented on COMPRESS-388:
-----------------------------------------
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/21
[](https://coveralls.io/builds/11199449)
Coverage decreased (-0.02%) to 84.214% when pulling
**3c8672db0a68dcd6b59c36abc3ec676b5af02f0a on
kvr000:feature/COMPRESS-388-concurrent-reads-performance-fix** into
**13a039029ca7d7fca9862cfb792f7148c555f05f on apache:master**.
> 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)
