GitHub user kvr000 opened a pull request:
https://github.com/apache/commons-compress/pull/21
COMPRESS-388: Fix concurrent reads performance
Ticket: https://issues.apache.org/jira/browse/COMPRESS-388
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).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kvr000/commons-compress
feature/COMPRESS-388-concurrent-reads-performance-fix
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-compress/pull/21.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #21
----
commit 3c8672db0a68dcd6b59c36abc3ec676b5af02f0a
Author: Zbynek Vyskovsky <kvr...@gmail.com>
Date: 2017-04-23T06:45:46Z
COMPRESS-388: Fix concurrent reads performance
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
