JDK-7099086 : Java Web Start 10.1.* is considerably slower than Web Start 1.4.2, using getresource() repeatedly
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
Java Web Start 10.1.0.8 (Java SE 7 Update 1) is considerably slower
compared to Java Web Start 1.4.2, when loading resources by
verified with 8 b108
Loaded classes 99 in 1141mills, loaded files 99 firsttime in 213mills second time in 130mills
Here is what happens:
1) Test application uses jar index
2) Test application consists of many jar files (100) that share same package names. Every jar has just one class in "test" package and 1000 other jar entries.
3) Test app tries to load classes from "test" package one by one.
4) Current implementation in DeployURLClassPath (and in fact URLClassPath
but this needs to be addresses on JDK side) performs validation of the jar index in case index points to jar as candidate to contain requested resource but resource is not found.
5) validation procedure checks jar has at least one entry in the requested
package. In the test scenario this means we iterate through 1000
entries in jar before we find index is ok. And we repeat it for every
false positive jar (remember they all have "test" package).
Total cost of "validation" for this scenario is 100*1000*(100/2)=5 000 000 jar entries read
(calculated as numberOfLookups*CostOfLookupInOneJar*AverageJarsToLookIn)
This is obviously expensive and real customer app is even bigger (1000+ jars) => possible even more expensive.
On other hand the value of this validation check is questionable
(originally was added in 2001, 1.3 timeframe).
The only outcome we get different exception instead of ClassNotFound.
In any case attempt to load class will fail. In case of malformed index
it will file with RuntimeException and apps may not be catching it.
Anyway, check does not seem to worth it.
Suggested fix is to remove validation check. With this change time for second stage
of test is reduced to about 100ms (from 10000ms) and this is comparable with what is reported for 1.4.2
Problem seem to be related to inefficient processing of indexed jar files.
More research is needed to identify best solution.
Suggested workaround: do not index jar files.