On Mon, Nov 14, 2016 at 1:29 AM, Luis Bernardo <[email protected]> wrote:
> Compression is preferred for archival and packaging purposes (for instance > debian packages require info documents to use compression 9). I think that > if we are generating PNG images for later use then using the value 9 makes > sense. Probably this should be configurable with the current value as the > default. > +1 > > On Mon, Nov 14, 2016 at 6:08 AM, David Vernet <[email protected]> wrote: > >> The tradeoff between using lower or higher compression / deflation >> metrics is latency / compression time -> file size. The higher the >> compression metric, the smaller the file but the longer it takes to >> compress / decompress it, and vice versa. In zlib land (which is what the >> Java Deflator class uses), the compression levels are: >> >> *#define Z_NO_COMPRESSION 0 >> #define Z_BEST_SPEED 1 >> #define Z_BEST_COMPRESSION 9 >> #define Z_DEFAULT_COMPRESSION (-1)* >> >> so changing the deflation metric to 1 optimizes for speed over >> compression / file size. I suppose what metric to use depends on the size >> of the file being encoded and the memory bandwidth of the system. >> >> I cannot speak to the reason it was originally set to 9, though I imagine >> it was either because optimizing for speed wasn't tried, or when that patch >> was first pushed, memory I/O was still the bottleneck in the system. >> Unfortunately, the commit associated with that change is enormous and has >> no comments: https://github.com/apache/batik/commit/aab0f40ddfab5b5dea926 >> b5b88a8b11803dfa4b6. I can't imagine any scenario where compression >> would be preferred over speed unless you're shipping the image over a slow >> network (though to be honest, I don't know enough about Batik to know if >> that's even possible / relevant -- my experience is limited to the Dacapo >> benchmark). >> >> On Sun, Nov 13, 2016 at 11:51 PM Glenn Adams <[email protected]> wrote: >> >>> Can you comment on the functional differences (if any) between using a >>> deflation metric of 1 or 9? Care to speculate why it is set to 9 at present? >>> >>> On Sun, Nov 13, 2016 at 5:44 PM, David Vernet <[email protected]> >>> wrote: >>> >>> Hello, >>> >>> I am a researcher in Java code optimization, and in my research I have >>> found an optimization for Batik (version 1.7) that provides a 4.8x >>> throughput improvement according to the Dacapo Benchmark Suite >>> <http://dacapobench.org/>. >>> >>> The optimization is obtained by changing this line >>> <http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/batik-codec/src/main/java/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java?view=markup#l451> >>> in >>> the PNGImageEncoder class: >>> private void writeIDAT() throws IOException { >>> IDATOutputStream ios = new IDATOutputStream(dataOutput, 8192); >>> // This line is the bottleneck. >>> DeflaterOutputStream dos = >>> new DeflaterOutputStream(ios, new Deflater(9)); >>> >>> By specifying a deflation/compression level of 1 instead of 9, >>> throughput is improved by 4.8x when run on the Dacapo benchmarking suite >>> (on my six-core Xeon e5-2620 v3 machine with a 15 MB L3 cache and 16 GB of >>> RAM). It appears that deflating a compressed image was a big bottleneck in >>> the system. Both my profiler, as well as Xprof and Hprof identified this >>> bottleneck. >>> >>> I have not tried running the benchmark on the latest code release (I ran >>> it on 1.7), but I see that the deflation metric is still set to 9 even on >>> the latest branch. >>> >>> I have no experience at all using Batik, but I thought you would be >>> interested in hearing about this potential very simple and significant >>> performance improvement for what seems like an important feature in the >>> library. Please let me know if you would like me to try re-running my >>> optimization on the latest codepath, and I will do so and let you know what >>> my results are. >>> >>> Regards, >>> >>> -- >>> David Vernet >>> Master of Science in Computer Science Student >>> Carnegie Mellon University >>> Class of 2016 >>> >>> >>> >
