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 >
