Optimizing archiver performance by sniffing file headers ?

[Kristian Rosenvold <kr...@gmail.com>]

In the following patch
https://github.com/krosenvold/plexus-archiver/commit/e525cf9ad07ef2e96b1c4281945c06e2f59f7d5a
I added sniffing of the file ZIP header to the "archive" function, and
if the file being added is already zipped, I store it instead of
deflating it
in the archive (avoiding recompressing the already compressed file).

This doubled the performance of the war plugin on my build. Is there
any reason why I can't just make this the default
behaviour of the archiver ?

(Making your JAR files uncompressed and then the WAR file compressed
sounds weird to me...?)

Kristian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Optimizing archiver performance by sniffing file headers ?

[Dawid Weiss <da...@gmail.com>]

> (Making your JAR files uncompressed and then the WAR file compressed
> sounds weird to me...?)

This may actually make sense since zipping an uncompressed ZIP file
will be more like tar/gz and will result in better compression
performance (because zip dictionaries are contiguous over multiple
files).

Proof of concept:

lucene/ files, zipped (max. compression): 30,535,633 bytes
lucene/ files, zipped (no compression):  64,491,998 bytes
zipped zip file (no compression): 27,265,084 bytes.

It's a compilation time/ size tradeoff in other words.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org