Ulf.Zibis at gmx.de
Mon May 18 17:11:28 PDT 2009
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. ;-)
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:
>> 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.
More information about the core-libs-dev