Hi all, the groovy parsing uses the official groovy parser, at the moment 2.5.x... I would assume that switching to 3.x would speed up the parsing due to the new parser in groovy 3..
I have a working prototype of using 3.x but a couple of tests are still failing... What are your tests based on? Spock? So maybe AST transforms have impact as well.. Additional idea, try to get on touch with the groovy people maybe your problem helps identifying bottlenecks in the parser.. Hope to spend some time to improve Groovy support over the holidays... Stay safe and healthy -Sven Geertjan Wielenga <[email protected]> schrieb am Fr., 18. Dez. 2020, 09:02: > This is all really great news, aside from the Groovy part. I don't believe > the parsing of Groovy files has been touched in the last 10 years or so, > anything you could do to work on that would be much appreciated by many. > > Gj > > On Fri, Dec 18, 2020 at 8:37 AM Tim Boudreau <[email protected]> wrote: > > > Hi, all, > > > > So, about 8 weeks ago I took a new job at Amazon, working on some > > server-side tools stuff. Amazon, famously, has their own build system > with > > some interesting quirks. Naturally I spent the first weekend after > > starting there writing a NetBeans plugin for it, which is getting pretty > > good - NetBeans project system is a much more natural fit for it than > what > > other IDEs offer. > > > > One thing is killing me, though: Lots of tests written in Groovy. I've > > managed to go to heroic lengths to manage the classpath and events fired > > from it with tweezers and get times reasonable for very large Java > > projects. > > > > But those that have hundreds or thousands of Groovy tests are just > brutal - > > as in, run test-single *once* and that triggers a full *source *scan, and > > for the next 20 minutes things like tab-expanding code templates and even > > fix imports hang for a long time followed by the dreaded "Lengthy > Operation > > in Progress" dialog. > > > > Anyone know of any way to improve this? Is there a newer, faster Groovy > > parser than whatever we're using that could be integrated? Other ideas? > > > > -Tim > > > > -- > > http://timboudreau.com > > >
