Hi, current implementation of ZipFile.getEntryPos takes the encoded byte[] of the String we're looking up. Which means when looking up entries across multiple jar files, we allocate the byte[] over and over for each jar file searched.
If we instead refactor the internal hash table to use a normalized String-based hash value, we can almost always avoid both the repeated encoding and (most of) the hash calculation when the entry is not found in the jar/zip. This realizes a significant startup improvement on applications with several or many jar files. A rather typical case. For example I see a 25% speedup of ZipEnty.getEntry calls on a Spring PetClinic, which reduces total startup time by ~120ms, or ~2.5% of total, on my setup. At the same time remaining neutral on single-jar apps. Webrev: http://cr.openjdk.java.net/~redestad/8243469/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8243469 Testing: tier1-2 Thanks! /Claes
