<div dir="ltr"><div>Hello,</div><div><br></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Mar 28, 2025 at 12:56 AM Jason Zaugg <<a href="mailto:jzaugg@openjdk.org">jzaugg@openjdk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A GitHub code search reveals this idea is also pursued in [Eclipse JDT](<a href="https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/e3fd9a0c74374951d4c91663a6fd52f16f6ee9c6/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/CachingJarsJavaFileManager.java#L45" rel="noreferrer" target="_blank">https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/e3fd9a0c74374951d4c91663a6fd52f16f6ee9c6/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/CachingJarsJavaFileManager.java#L45</a>). So any change to `getJarFsProvider`.<br></blockquote><div><br></div><div>I've been following that thread as I'm always 
looking for ideas to improve the performance of the Javac integration in
 JDT mentioned below. Thanks for the discussion!</div><div>The
 general and not-new idea is that Javac is currently optimized for a single run from
 CLI, by integration in Eclipse IDE/JDT, we want to make it a 
long-living framework (so do all IDEs). So we do have to implement several caches here 
and there to not spend too much CPU repeating constantly the same tasks.
 Loading Jars (FileManager/FileSystem) has been by far the most 
important thing for which to implement some caching. We currently cache the FileSystems and got good results for it. But as the discussion mention, we might also consider caching the FileObject and some of it's commonly requested values, to save some more reading of the streams. I actually believe it's the strategy used by Netbeans.</div><div><br></div><div>But ideally, we'd even go further and allow caching the Symbols from the jars and just reuse them. They are currently always recreated by ClassReader re-reading the zips and this isn't a cheap operation... I believe some ClassReaderWithSymbolCache would make the biggest difference now (basically storing a trimmed version for the symbols it has loaded, and just copying the relevant info from these symbols it has already loaded to further requested symbols instead of reading in the jar again); and such a cache would probably make all lower-level optimization that we have in place useless as the underlying filesystems used by the symbols would remain across requests (we just have to take care of not closing them!)...</div><div>I wish to investigate that in a near-ish future. I will try to report whether this has proven to be a good idea or not then.</div><div><br></div><div>Anyway, this is becoming a much divergent story from the initial discussion, so I'll just mention here that if one uses some sufficient caching strategy, this `zipinfo-time` tweak becomes much less critical (since the related operations happen only once per jar, which easily becomes neglect-able over re-reading zips several times for no new reason).</div><div><br></div><div>Cheers</div></div></div>