Cédric, Thanks for your response. In this case, no, I am adding fully-qualified single class names (see the pastebin <http://pastebin.com/V1ijXPjC> example).
Scott On Fri, Nov 20, 2015 at 3:11 PM, Cédric Champeau <cedric.champ...@gmail.com> wrote: > Are the imports you are adding star imports? If so, it is likely the > problem. If you know the exact classes that you want to import, it is > better to import them as fully qualified class names. I had a similar issue > with Gradle recently, and it has been partly mitigated with this commit: > https://github.com/gradle/gradle/commit/42e9f41e41880178aa85ebac6956690c711c7130 > > I'm pretty sure we can improve resolution time by providing better > knowledge to the compiler of what imports are possible. > > 2015-11-20 21:05 GMT+01:00 Goo Mail <goomai...@gmail.com>: > >> Hi all, >> >> I am using Groovy embedded into an application which runs user-provided >> scripts. I see a significant parsing performance issue when the compiler is >> configured to add ~30 automatic imports via an ImportCustomizer, but I >> can't figure out why it is happening. >> >> For various unrelated reasons, we segregate individual user scripts by >> creating a new GroovyClassLoader for each one and parsing each script in >> its own context. (These classloaders all chain to a single parent Groovy >> classloader that contains some shared functionality.) >> >> With the scripts segregated like this, I noticed that even an empty >> script takes 300+ ms to parse, which seems excessive. If I remove the >> automatic imports, the parse takes <10 ms instead. But I also found >> something bizarre in how the CompilerConfiguration seems to influence the >> parse time. >> >> I am 99% sure that the parsed class is not cached, since I turned off all >> of those options and I also stepped into the parse() function to confirm >> that it was walking through all of the phases. >> >> Could it be that the extra time is actually consumed by loading/resolving >> the imported classes, and not something Groovy is manipulating during the >> parse itself? That seems possible (and is potentially understandable, at >> least on the first invocation), except for one weirdness: >> >> The parse time problem appears tied to the specific instance of a >> CompilerConfiguration object being provided to the child classloader. For >> example, when creating the child classloader, if I supply the same >> CompilerConfiguration object that was provided to the parent classloader, >> the parse time suddenly get very fast! >> >> But if I instead construct a new CompilerConfiguration object for every >> script, the parse is very slow, even though the newly-constructed CC is >> identical to the previous one, and even though each script is still using >> its own separate classloader. >> >> What is going on (and how do I fix it)? Here is an example that you can >> run in groovysh that demonstrates the problem: >> >> http://pastebin.com/V1ijXPjC >> >> Here is the output: >> >> ===> true >> Showing slow parse time >> Parse time: 281 ms >> Parse time: 260 ms >> Parse time: 280 ms >> Parse time: 277 ms >> Parse time: 259 ms >> Parse time: 257 ms >> Parse time: 279 ms >> Parse time: 260 ms >> Parse time: 278 ms >> Parse time: 282 ms >> ===> null >> Showing fast parse time >> Parse time: 280 ms >> Parse time: 3 ms >> Parse time: 3 ms >> Parse time: 2 ms >> Parse time: 3 ms >> Parse time: 2 ms >> Parse time: 2 ms >> Parse time: 3 ms >> Parse time: 3 ms >> Parse time: 2 ms >> ===> null >> >> Thanks for any insight you can provide! >> >> - Scott >> >> >
