[jira] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[jira] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries

JIRA jira@apache.org

    [ 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:
+1

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@.../msg37807.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
Loading...