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.
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).
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
