[
https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315884#comment-16315884
]
Dirk Rudolph commented on JCRVLT-163:
-------------------------------------
I did a quick search on the difference between NO_COMPRESSION and the STORED
method and found:
https://stackoverflow.com/questions/35141580/zipentry-stored-for-files-that-are-already-compressed
{quote}
The ZipOutputStream.setLevel(NO_COMPRESSION/DEFAULT_COMPRESSION) hack is not a
viable approach. I did extensive tests on hundreds of gigs of data, thousands
of folders and files and the measurements were conclusive. It gains nothing
over calculating the CRC for the STORED files vs compressing them at
NO_COMPRESSION. It is actually slower by a large margin!
{quote}
> Avoid compressing incompressible binaries
> -----------------------------------------
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Affects Versions: 3.0
> Reporter: Timothee Maret
> Fix For: 3.1.40
>
> Attachments: JCRVLT-163.patch
>
>
> As discussed in [0], this issue tracks allowing to specify the compression
> level when building packages. The primary idea is to avoid compressing
> (compression level = {{NO_COMPRESSION}}) already compressed binaries,
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two.
> Therefor, it may make sense to allow configuring the compression levels per
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
