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 <[email protected]>:
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/view_bug.do?bug_id=6818736
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=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
