NOBODY said:
would it improve startup time to split rt.jar into many jars?
The ZIP file format has a "table of contents" at the end which allows an
application to find sub-files within it without having to scan through the
whole file. I assume that the JVMs' internal zip file readers will be smart
enough to use that. So as a first approximation I wouldn't expect splitting
the jars to make any difference at all.
That said, there may be secondary effects. Large files may require more levels
of indirection in the file system's disk format, so -- at least
theoretically -- it might take longer to do random access in a large file than
a smaller one. I doubt if rt.jar is big enough for that to matter, though. Of
course, scanning the table itself takes some time too, and splitting rt.jar
might allow the JVM to do less work there -- but (without having measured it)
my guess is be that the time taken to read the table is not a significant
factor.
Another possibility, not directly related to splitting rt.jar, is that seeking
in file is a relatively expensive process if it results in actual disk head
movements (if the jump is to a place in the file that is not cached by the OS,
or the disk controller). There may be scope for optimising the order of files
in rt.jar to attempt to minimise the amount of disk-head movement when starting
typical applications. I don't know if anyone has ever tried to do such
optimisation (and the way java code breaks down into packages may tend to group
related code together anyway).
Come to think of it, I'm not convinced that using an uncompressed format for
rt.jar is necessarily a good idea itself. If the .class files were compressed
then there'd be less data to cache, less data to stream off disk, and fewer
head movements. Those gains might easily more than make up for the extra cost
of decompression on many machines. I haven't tested it. Maybe I will
someday...
-- chris
