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,
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.
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.
Sherman
