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
