jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothee Maret (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries
Date Thu, 01 Jun 2017 09:57:04 GMT

    [ https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032718#comment-16032718

Timothee Maret commented on JCRVLT-163:

Thanks [~tripod] for looking at this and for the suggestions. I'll update the branch https://github.com/tmaret/jackrabbit-filevault/tree/JCRVLT-163

bq. optimize your test output stream, by also overriding the other write() methods:

bq. your tests take a very long time 

IIRC {{CompressionUtilTest}} is a unit test that should run quickly and {{TestCompressionExport}}
was meant as a performance integration test such that we could get tweak the offsets (e.g.
{{MIN_AUTO_DETECTION_LENGTH}}). As is, I think the performance integration test should not
run as part of the regular build because I. it takes too long to run and II. some of the assertions
are likely to fail from time to time (test heavily dependent on timing).

Since the test is likely to fail from time to time, I suggest to ignore the {{TestCompressionExport}}
by default.

bq. and seem to fail when there is nothing to optimize.

Ok, I'll look at it again.

> 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

View raw message