You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Tim Boudreau <ni...@gmail.com> on 2020/12/18 07:36:46 UTC
Abominable Groovy scanning performance
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
Re: Abominable Groovy scanning performance
Posted by Jaroslav Tulach <ja...@gmail.com>.
> 18. 12. 2020 v 9:01, Geertjan Wielenga <ge...@googlemail.com.invalid>:
>
> This is all really great news,
Tím helping James Gosling to promote Amazon offerings thru improving NetBeans! Two NetBeans old time supporters being paid to cooperate in a direction that ultimately has to make NetBeans better?
Yes! That’s very good news. Good luck!
-jt
> 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 <ni...@gmail.com> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Abominable Groovy scanning performance
Posted by Sven Reimers <sv...@gmail.com>.
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 <ge...@googlemail.com.invalid> 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 <ni...@gmail.com> 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
> >
>
Re: Abominable Groovy scanning performance
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <ni...@gmail.com> 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
>