>I think that if we are generating PNG images for later use then using the value 9 makes sense.
Sounds good. Just so you're aware, however, there is an "inflection point" in that choosing a deflation metric of 7 still gives you a speedup of 3.33x, while a deflation metric of 8 gives you about a 2x speedup. I don't know exactly what the expected compression ratio differences are for levels 7, 8, and 9, but if the differences are generally on the lower side, the benefit of the lower latency may outweigh the benefit of the extra compression. On Mon, Nov 14, 2016 at 3:58 AM Glenn Adams <[email protected]> wrote: > 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/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 > > > >
