Miscellaneous improvements to "jar".

[Ulf Zibis]

Am 26.06.2009 20:28, Ulf Zibis schrieb:
> Am 26.06.2009 18:45, Xueming Shen schrieb:
>> Ulf Zibis wrote:
>>>
>>> Motivation:
>>> Xueming states:
>>> *"dat" based uses less disk space, but it has larger startup time, 
>>> reading an additional "big" dat file during class 
>>> loading/initializing actually takes much longer time than I expected 
>>> (I hit the extreme when I worked on the EUC_TW, which I make the 
>>> size only 30% of the existing one, but startup is a disaster 
>>> regression, ...
>>> *
>>> If loading x bytes from dat file via getResourceAsStream() takes 
>>> much longer time than loading x+30% bytes from class file, 
>>> processing the UTF-8 conversion, instantiating and initializing 
>>> additional Class objects, I imperatively presume, that there must be 
>>> a big chance for significantly improving read speed from 
>>> uncompressed jar file (here charsets.jar), by using direct channels 
>>> or how ever. I presume, enhancing reading from jar files would be a 
>>> big fish in performance gain for the whole JDK, as it is very common 
>>> task in JVM's daily work.
>>>
>>>
>> Ulf, the "jar reading" part of the "class loading/initializing" of 
>> charsets.jar (and most of the "core lib" jars) is not via 
>> java.util.jar/zip interface,
>
> Oops, sorry for misunderstanding ...
>
>> there is a native level interface for the vm to access those jar 
>> files, so adding a nio buffer interface is not going to help startup 
>> of jdk/jre itself.
>
> ... I was only thinking about the numerous "resources" loaded on 
> startup of jdk/jre AND later from user application, and, of course, 
> for more motivation to avoid heavy static data in class files.

To give additional motivation on jar-lib performance, I have attached 
result from NetBeans slowness detector while project scan.
As you can see, reading from zip files should be a big fish for 
performance improvement.

> Additionally, some time ago on a debug session through 
> getResourceAsStream(), I noticed, that the construction of the 
> resources file's URL seams to be very wasteful (looping 
> StringBuffer#apend() char by char (or even strings of length 1), even 
> on 50..100 chars long Strings).

Additionally ...findClassPathImpl() slowness is *maybe* caused by slow 
construction of the resources file's URL

Regards,

Ulf


>
> Any chance about outsourcing some code from API's jar code to native 
> code, so API customers could profit from the speed of the native level 
> interface of the vm to access jar files?
>
>> Martin's estimate of 10%-20% gain indeed is very close, I got less 
>> than 5%-8% (for jaring) gain from my prototype implementation. As I
>> said it's still something worthing doing, especially it makes the 
>> life easier when work together with other nio/channel APIs.
>
> I agree!
>
> -Ulf
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NetBeans Slowness detector result.png
Type: image/png
Size: 120191 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090629/d69fd8a9/NetBeansSlownessdetectorresult.png>