Hello, I've been looking into ZipFile again with the aim to speed up typical enterprise classloading / resource lookups.
To test the performance impact of my changes, I made a benchmark which creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar files in Spring Petclinic (89 jars with ~30k entries total). (This is intentionally implemented using a plain main method with no JMH or warmup since I want to measure a representative cold application startup) The benchmark measures the time needed to call getResource 30K times, once for each entry name. Using 15.0.1, this completes in ~1700 ms Using 17 master, it completes in 12851 ms If I run the benchmark from the classpath instead of as a module, the result is even worse: 15: 1724 ms 17: 21885 ms If also measure GC collections and times, and get the following: 15: Collections: 4 Collection time: 12 ms 17: Collections: 24 Collection time: 44 ms (However, a JHM with -prof gc indicates that both 17 and 15 allocate ~5.6Kb/getResource after warmup, so not convinced this needs to be allocation related) The EnterpriseClassLoader is a bit clever in that it can perform lookups using different strategies: Regular parent-first, self-only, or use the bootstrap / platform system classloaders directly. Here are the results on 17 using each strategy (benchmark on class path): PARENT_DELEGATION: 23111 ms SELF_ONLY: 428 ms BOOTSTRAP: 8131 ms PLATFORM: 15149 ms SYSTEM: 20628 ms Here are the same results on 15: PARENT_DELEGATION: 1691 ms SELF_ONLY: 393 ms BOOTSTRAP: 579 ms PLATFORM: 908 ms SYSTEM: 1368 ms Note that the delegation chain is Enterprise -> System -> Platform -> Bootstrap. Interesting to note that URLClassLoader itself does not seem to regress much when only looking up its own resources, while delegating up the chain does. Has there been any significant work in class loading / resource lookup since 15.0.1 that could help explain this regression? Eirik.
