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.
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/ > aab0f40ddfab5b5dea926b5b88a8b11803dfa4b6. 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 >> >> >>
