Improving ZipFile.getEntry performance using Bloom filters

[Claes Redestad]

On 2020-04-15 00:34, Ioi Lam wrote:
>>
> I am a little worried adding extra overhead unconditionally into the JAR 
> reader that people may not need/want.
> 
> Maybe we should take a step back and see why there are so many misses? 
> Is it because you have a long classpath with many JARs on it, and you 
> end up searching a lot of JAR files unnecessarily?
> 
> If this is the case, I think converting the app to modules will give you 
> the speed up. A package can exist only in a single module so lookup is 
> fast. You won't have misses unless you intentionally look for things 
> that don't exist.
> 
> Or, you can just package the app into one giant JAR file.

Yes, I think the constraint on any optimizations here is that it
shouldn't regress anything we can think of. Especially not already-
optimized deployments - be they using modularized apps, fat jars or
AppCDS.

But I think we should improve the lowest common denominator OOTB
experience when we can. And after some back and forth with Eirik off-
list I think there are improvements we can do in this area which will be
wins for many and a regression for no-one (at least not in any
detectable way).

A bloom filter might not be it, since it would add noticeable overhead
for fat jar deployments. So... stay tuned..? :-)

Thanks!

/Claes