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 > > >
