Inflater/Deflater improvements

[Ulf Zibis]

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/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
>>
>>
>>
>>     
>
>
>