sdedic opened a new pull request #3213: URL: https://github.com/apache/netbeans/pull/3213
Groovy parser creates two class loaders - as Groovy compiler uses ClassLoader API to reach out for resources in the user project and/or libraries: * `ParsingClassLoader`, which should serve files from user project, sources etc. It is used for symbol or resource resolution. * `TransformationClassLoader` whose job is to load extensions to the Groovy Compiler, visitors and transformers. The distinction is that while the user project's content may change (user rewrites some files, adds or removes some from the project), so contents of *Parsing* Classloader should be thrown away, the classes loaded by *Transformation* ClassLoader are not intended to be part of user project, rather they become part of the IDE runtime. So far, those classes are loaded to JVM during each parse request - performing all startup linking, verification - AND initialization. It's less visible during *indexing*, as the whole root is indexed using one set of classloaders, but has big impact on *ad hoc parsing* tasks like code completion, refrence search, semantic highlight etc. The issue is highly visible on projects that use sophisticated libraries that add Groovy transformation visitors - which are likely to use its library classes so they are incorporated into IDE's runtime (and then thrown away). This PR creates a **classloader cache** for the Transformation classloader. The cache is local to a project, so the contents eventually vanishes after the project closes. One instance of the cache is *global* to cover files that do not belong to any project. The cache is size-bound and expires (`TimedSoftReference`) its content after ~30 sec of inactivity (provided the classloader is not referenced from anywhere). The cached classloader monitors set of roots of the ClassPath it was created for; if the set of roots changes, the classloader invalidates itself - a new one will be created on next parse request. The validation is also done during parsing startup, so the parser should always start with a consistent state. The speedup for completion is again on scale of a magnitude: instead of ~10-12 seconds (micronaut-core project), the completion now appears after about 0.5-2 secs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
