commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zbynek Vyskovsky (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-388) Improve concurrent reads from ZipFile
Date Sun, 23 Apr 2017 15:21:04 GMT


Zbynek Vyskovsky commented on COMPRESS-388:

Stefan: Sorry, github detected my commit as a spam probably and blocked (hid) my account.
Now it should be visible again.

In the meantime I improved the coverage by creating src/test/resources/, containing
two relatively big files, one inflated, one stored. And various ways are used to read the
file, in order to properly test cache read, big reads and their combination (to check whether
the already cached bytes are not discarded etc.). And not surprisingly, it discovered a bug.

> Improve concurrent reads from ZipFile
> -------------------------------------
>                 Key: COMPRESS-388
>                 URL:
>             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

View raw message