Miscellaneous improvements to "jar".
Ulf.Zibis at gmx.de
Mon Jun 29 21:38:55 UTC 2009
Am 26.06.2009 20:28, Ulf Zibis schrieb:
> Am 26.06.2009 18:45, Xueming Shen schrieb:
>> Ulf Zibis wrote:
>>> 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
> 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
> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NetBeans Slowness detector result.png
Size: 120191 bytes
Desc: not available
More information about the core-libs-dev