Inflater/Deflater improvements (original) (raw)

Ulf Zibis Ulf.Zibis at gmx.de
Tue May 19 00:11:28 UTC 2009

Clemens, Sherman,

you are right. Oops!

But there is another bottleneck, where both are concerned from: If used by ZipFile#getInputStream(ZipEntry entry), the underlying BufferedInputStream is very slow because of internal copying. I'm sure, direct ByteBuffer, served from getChannel(ZipEntry entry), would be faster. ;-)

-Ulf

Am 18.05.2009 21:03, Clemens Eisserer schrieb:

Hi Ulf,

I don't think the JVM uses the Inflater/Deflater classes directly, but instead accesses zblib directly - but I could be wrong. Furthermore as far as I know charsets.jar isn't compressed. The patches only try to remove some horrible memcpy overhead in some common situation. - Clemens 2009/5/18 Ulf Zibis <Ulf.Zibis at gmx.de>:

Am 04.05.2009 23:38, Martin Buchholz schrieb:

I think many people will be interested in performance improvements in Inflater/Deflater. I may have time to help review.

Yes, there is also interest from charset de/encoding side. See: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6818736 http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6818737 Current charset mapping tables are hosted as huge String constants inside charset classes. Hosting them as resource data files would would avoid ~50 % disk-footprint wastage of the charsets.jar. Additionally sharing of overlapping charset mapping data would become manageable. Currently we only have ClassLoader#getResouceAsStream() to load such data files, but we can't use it, because the underlying buffered stream is too slow in respect of JVM startup time. We need fast nio direct buffer access via java.nio.channels.Channel to load the data from charsets.jar. So improving performance of jar/zip file access would be much appreciated. :-) -Ulf

More information about the core-libs-dev mailing list