You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@groovy.apache.org by Paolo Di Tommaso <pa...@gmail.com> on 2020/01/16 21:59:49 UTC

Re: Groovy 3 very slow stub generation

Hi Daniel,

I've made the test you suggested:

   - The gradle build with groovy 2.5.8 compiles in 34 seconds
   - The gradle build with groovy 3.0.0-rc-3 takes 1m 46s
   - The build with IntelliJ more than 5 minutes, which makes it unusable :(


p

On Mon, Nov 18, 2019 at 4:04 PM Daniel.Sun <su...@apache.org> wrote:

> Hi Paolo,
>
>       Please do experiment through the following steps:
> 1)  In your command line(e.g. under Windows OS, type `cmd` to open it), run
> `gradlew compileGroovy --no-build-cache` to compile with 3.0.0-rc-1 and
> 2.5.x
> 2)  Compare the time cost by 3.0.0-rc-1 and 2.5.x
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

I tried to remove  the following error alternative of `rparen`, parsing all
groovy source files under nextflow module[1] with 4.0.0-SNAPSHOT takes only
"14s".
https://github.com/apache/groovy/blob/GROOVY_3_0_0_RC_3/src/antlr/GroovyParser.g4#L1232-L1234

*4.0.0-SNAPSHOT antlr4 parser: 14s*
result-4.log <http://groovy.329449.n5.nabble.com/file/t340716/result-4.log>  
profile-4.zip
<http://groovy.329449.n5.nabble.com/file/t340716/profile-4.zip>  

*4.0.0-SNAPSHOT antlr2 parser: 6s*
result-2.log <http://groovy.329449.n5.nabble.com/file/t340716/result-2.log>  
profile-2.svg
<http://groovy.329449.n5.nabble.com/file/t340716/profile-2.svg>  

Cheers,
Daniel.Sun
[1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow






-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

The current result of parsing all groovy source files under nextflow
module[1] with 3.0.0-rc-3 and the distribution built from master.

After some rules tweaked,  about 39.8% time is saved util now(Formula: (103s
- 62s) / 103s = 39.8%). 

*3.0.0-rc-3 costs 103s*
result-3.log <http://groovy.329449.n5.nabble.com/file/t340716/result-3.log>  
profile-3.svg
<http://groovy.329449.n5.nabble.com/file/t340716/profile-3.svg>  

*4.0.0-SNAPSHOT costs 62s*
result-4.log <http://groovy.329449.n5.nabble.com/file/t340716/result-4.log>  
profile-4.svg
<http://groovy.329449.n5.nabble.com/file/t340716/profile-4.svg>  

Sam and I are still trying to tune the performance of the antlr4 parser.
Thanks a lot for your help, Sam :-)

Cheers,
Daniel.Sun
[1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Hi Paolo,

     As you can see, Sam and I have been trying to improve the performance
of the antlr4 parser recently. I believe the performance could be improved a
lot, but antlr4 parser will be slower than antlr2 parser as a whole finally
due to the following reasons(including but not limited to):

1) Groovy 3's grammar is more complicated than Groovy 2's
2) Different algorithms used by antlr2 and antlr4, as I said in the previous
email

> What is the maximum number of lines of code that a source file should
> contain to prevent perf degradation? 
It needs some tests. Let's wait for the tuning result ;-)

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by Paolo Di Tommaso <pa...@gmail.com>.

What is the maximum number of lines of code that a source file should
contain to prevent perf degradation?



On Fri, Jan 31, 2020 at 8:16 PM Daniel.Sun <su...@apache.org> wrote:

> I find antlr4 parser parses *big* files much slower than antlr2 parser,
> unfortunately nextflow project contains quite a few big files...
>
> One of reasons is antlr2 uses LL(k) and antlr4 uses ALL. As we know, LL(k)
> will look ahead *limited* count of tokens, but ALL will look ahead
> *unlimited* count of tokens...
>
> I am trying to tweak rules to reduce looking ahead, but we have to admit
> that Groovy's grammar contains ambiguities, one of main reasons is
> parenthesis-less... As a user, I like it, but as a developer, I hate it...
>
> Cheers,
> Daniel.Sun
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

RE: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

I find antlr4 parser parses *big* files much slower than antlr2 parser,
unfortunately nextflow project contains quite a few big files...

One of reasons is antlr2 uses LL(k) and antlr4 uses ALL. As we know, LL(k)
will look ahead *limited* count of tokens, but ALL will look ahead
*unlimited* count of tokens...

I am trying to tweak rules to reduce looking ahead, but we have to admit
that Groovy's grammar contains ambiguities, one of main reasons is
parenthesis-less... As a user, I like it, but as a developer, I hate it...

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

RE: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Hi Eric,

      Thanks a lot for your help. The top time-consuming method `closure` is
an internal method of the implementation of antlr4. It's hard for us to
change. Luckily, Sam Harwell, the co-author of antlr4, is trying to help us
tune the performance of the antlr4 parser, too. But Groovy's grammar is
quite complicated and contains some ambiguities, so it's hard to tune...
fingers crossed...

      Also, I have an idea as a workaround: let's initialize the DFA cache
by parsing usual code snippets, then serialize the DFA cache into a file,
which will be bundled in the groovy-3.0.0.jar. When groovy starts, the file
containing the DFA cache will be loaded, thus the performance of parsing can
be improved a lot at the first time of parsing.

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

RE: RE: Groovy 3 very slow stub generation

Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.

I took a look at the nextflow test (added a 100.times loop around the antlr4 compile to increase the sample size) in jvisualvm.  In my sample collection (included below) org.antlr.v4.runtime.atn.ParserATNSimulator.closure(ATNConfig, ATNConfigSet, ATNConfigSet, Set<ATNConfig>, boolean, boolean, PredictionContextCache, int, boolean) used about 1/3rd of the compute time.



I tried making some minor changes to the closure and getEpsilonTarget methods, but wasn't able to achieve more than 2-4% improvement.  So, I think performance improvements will need to come from some of the other 10%-ish methods or from changes to the parser grammar that can reduce the number of transitions that need to be explored in the parse graph.



[cid:image001.png@01D5D766.3545CAA0]









-----Original Message-----
From: Daniel.Sun <su...@apache.org>
Sent: Wednesday, January 29, 2020 3:25 PM
To: dev@groovy.incubator.apache.org
Subject: RE: RE: Groovy 3 very slow stub generation



Here is the flame graph for parsing all groovy source files under nextflow module[1] with the distribution built from master.



profile.svg <https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_file_t340716_profile.svg&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=TYmcOsETGHf1edCwWcLzRlUkEd_PF4RAn4e8iU-wZG0&s=zbVR_UFcVm2aox5USlCnz87SRu-F3QS1uBFuhfcixt8&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_file_t340716_profile.svg&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=TYmcOsETGHf1edCwWcLzRlUkEd_PF4RAn4e8iU-wZG0&s=zbVR_UFcVm2aox5USlCnz87SRu-F3QS1uBFuhfcixt8&e=%20> >



Cheers,

Daniel.Sun

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nextflow-2Dio_nextflow_tree_master_modules_nextflow&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=TYmcOsETGHf1edCwWcLzRlUkEd_PF4RAn4e8iU-wZG0&s=GJ1f550pn5P_L1IMZDISe3B67vkNwRxR6UMN6sK6eUo&e=









-----

Apache Groovy committer & PMC member

Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=TYmcOsETGHf1edCwWcLzRlUkEd_PF4RAn4e8iU-wZG0&s=tOQaYLayumIHoyB0huGHV2uCTgQfH2DpTux-LGJA1Sw&e=

Twitter: @daniel_sun



--

Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=TYmcOsETGHf1edCwWcLzRlUkEd_PF4RAn4e8iU-wZG0&s=WHRzQw88bMzPD29IhYV5cAXI4ZhmUJH_3s6BQKKdTlY&e=

RE: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Here is the flame graph for parsing all groovy source files under nextflow
module[1] with the distribution built from master.

profile.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile.svg>  

Cheers,
Daniel.Sun
[1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow




-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

RE: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Here is the flame graph for parsing all groovy source files under nextflow
module[1] with 3.0.0-rc-3
profile-3.svg
<http://groovy.329449.n5.nabble.com/file/t340716/profile-3.svg>  

Cheers,
Daniel.Sun
[1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

RE: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Here is the flame graph for parsing all groovy source files under nextflow
module[1] with the distribution build from master branch[2]

profile.svg <http://groovy.329449.n5.nabble.com/file/t340716/profile.svg>  


Cheers,
Daniel.Sun
[1] https://github.com/nextflow-io/nextflow/tree/master/modules/nextflow
[2] https://github.com/apache/groovy



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

RE: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

I created a branch to reproduce the performance issue:
https://github.com/apache/groovy/commits/nextflow-perf-issue

Here is the test:
https://github.com/apache/groovy/blob/nextflow-perf-issue/src/test/groovy/bugs/StubGenTest.groovy

After you run the test, you will find Parrot parser runs slower at the first
time, and will be much faster when run twice, but still slower than antlr2
parser.

Any help is appreciated :-)

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by Paolo Di Tommaso <pa...@gmail.com>.

This sounds great!

On Sun, Jan 19, 2020 at 7:48 PM Daniel.Sun <su...@apache.org> wrote:

> Hi Paolo,
>
>      I'm thinking about how to solve the performance issue:
>
> 1) Improve the performance of Parrot parser even if the groovy code is
> parsed for the first time
> 2) Generate stubs in parallel
>
> Cheers,
> Daniel.Sun
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

RE: RE: Groovy 3 very slow stub generation

Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.

I'd be glad to take a look at the current performance of the antlr4 parser.  Is there a specific test fixture that I can use?

-----Original Message-----
From: Daniel.Sun <su...@apache.org> 
Sent: Monday, January 20, 2020 11:14 AM
To: dev@groovy.incubator.apache.org
Subject: RE: RE: Groovy 3 very slow stub generation

Agreed. If time allowed, I prefer to profile and tune the performance.
BTW, if you could do a favor, that would be great.

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=iA1dB6PNEgZDlPDfWzLxH2-pYIW3bK12TcA6OxWXCgE&s=FxuREpUoq0VEQdfOUaVfDskwKWelC_XNCCXXEoao0mo&e=  
Twitter: @daniel_sun 

--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=iA1dB6PNEgZDlPDfWzLxH2-pYIW3bK12TcA6OxWXCgE&s=uRbulkHUheX9M4ehl2sIfdDiHWaLbPXgy1ckRl80WDc&e=

RE: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Agreed. If time allowed, I prefer to profile and tune the performance.
BTW, if you could do a favor, that would be great.

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

RE: RE: Groovy 3 very slow stub generation

Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.

How about running a profiler on the parser code?  The antlr2 parser did not need parallel stub generation to get an acceptable result.

-----Original Message-----
From: Daniel.Sun <su...@apache.org> 
Sent: Sunday, January 19, 2020 12:50 PM
To: dev@groovy.incubator.apache.org
Subject: Re: RE: Groovy 3 very slow stub generation

Hi Paolo,

     I'm thinking about how to solve the performance issue:

1) Improve the performance of Parrot parser even if the groovy code is parsed for the first time
2) Generate stubs in parallel

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member
Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=PNRUWHa-kJPFYbWBru4n1_0VjfGwQsr390C7zxs4JjU&s=Kij6ulvUgz64rndfKAFybpH1w_PA8yY1t5RdSpomZ5I&e=
Twitter: @daniel_sun 

--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=PNRUWHa-kJPFYbWBru4n1_0VjfGwQsr390C7zxs4JjU&s=L8MVQoUB_JYaPrML21s6gkihUQ8vctcQhyS3gQipfbM&e=

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Hi Paolo,

     I'm thinking about how to solve the performance issue:

1) Improve the performance of Parrot parser even if the groovy code is
parsed for the first time
2) Generate stubs in parallel

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by Paolo Di Tommaso <pa...@gmail.com>.

Hi Daniel,

Thanks for looking at this. I've reported the problem in the IntelliJ issue
tracking. Let me know if I can help further.

https://youtrack.jetbrains.com/issue/IDEA-230943


Cheers,
Paolo


On Sun, Jan 19, 2020 at 12:15 PM Daniel.Sun <su...@apache.org> wrote:

> Hi Paolo,
>
> When stubs are being generated, the first stubs generation will probably
> miss cache, but the performance of Parrot parser relies on its cache
> heavily, so it will run faster and faster while cache is filled fuller and
> fuller, which is the reason why antlr4 recommends NEVER clear its cache.
>
> In this case, I suggest enable gradle's build cache, it will run slower at
> the first time and the subsequent building will be faster.
>
> It takes about 81.572s to generate stubs for :nextflow module with Parrot
> parser for the first time, but IntelliJ IDEA takes more than 5 minutes to
> build, I think JetBrains team should address the cause.
>
> Cheers,
> Daniel.Sun
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Hi Paolo,

When stubs are being generated, the first stubs generation will probably
miss cache, but the performance of Parrot parser relies on its cache
heavily, so it will run faster and faster while cache is filled fuller and
fuller, which is the reason why antlr4 recommends NEVER clear its cache.

In this case, I suggest enable gradle's build cache, it will run slower at
the first time and the subsequent building will be faster.

It takes about 81.572s to generate stubs for :nextflow module with Parrot
parser for the first time, but IntelliJ IDEA takes more than 5 minutes to
build, I think JetBrains team should address the cause.

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Generating stubs with antlr2 parser is much faster than parsing with antlr2
parser, if we can work out the cause, the performance issue of generating
stubs with antlr4 can be solved. Assuming some operations are skipped.

Here is the labs branch:
https://github.com/apache/groovy/tree/nextflow-perf-issue

I wish we could address the issue ASAP, any help would be appreciated ;-)

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

The performance issue can be reproduced by the following script, which is
placed under "nextflow-master\modules\nextflow" directory:


(GenerateStubs.groovy)
```
def ant = new groovy.ant.AntBuilder()

ant.project.baseDir = new File('.')

ant.delete(dir: 'build')
ant.mkdir(dir: 'build')

ant.taskdef(name: 'generateStubs', classname:
'org.codehaus.groovy.ant.GenerateStubsTask')

def b = System.currentTimeMillis()
ant.generateStubs(srcdir: 'src', destdir: 'build')
def e = System.currentTimeMillis()

println "${(e - b) / 1000}s elapsed"

def buildDir = new File(ant.project.baseDir, "build")
println buildDir.list()
```


The steps to reproduce the performance issue:
```
D:\_TEMP\nextflow-master\modules\nextflow>set JAVA_OPTS=-Xms2g -Xmx2g
-Dgroovy.antlr4.cache.threshold=600 -Dgroovy.antlr4=false

D:\_TEMP\nextflow-master\modules\nextflow>groovy GenerateStubs.groovy
   [delete] Deleting directory
D:\_TEMP\nextflow-master\modules\nextflow\build
    [mkdir] Created dir: D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generating 611 Java stubs to
D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generated 779 Java stub(s)
7.977s elapsed
[FunctionalTests.java, groovy, misc, nextflow, test]

D:\_TEMP\nextflow-master\modules\nextflow>set JAVA_OPTS=-Xms2g -Xmx2g
-Dgroovy.antlr4.cache.threshold=600 -Dgroovy.antlr4=true

D:\_TEMP\nextflow-master\modules\nextflow>groovy GenerateStubs.groovy
   [delete] Deleting directory
D:\_TEMP\nextflow-master\modules\nextflow\build
    [mkdir] Created dir: D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generating 611 Java stubs to
D:\_TEMP\nextflow-master\modules\nextflow\build
[generateStubs] Generated 779 Java stub(s)
81.572s elapsed
[FunctionalTests.java, groovy, misc, nextflow, test]

D:\_TEMP\nextflow-master\modules\nextflow>

```

I am quite curious about the antlr2 parser result "7.977s" because "57.177s"
cost when we parsed all the groovy source files with antlr2 parser[1]

Cheers,
Daniel.Sun
[1]
http://groovy.329449.n5.nabble.com/Groovy-3-very-slow-stub-generation-tp5762698p5764332.html




-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by Paolo Di Tommaso <pa...@gmail.com>.

Hi,

Using "-Dgroovy.antlr4=false", it takes 38s, therefore, it is similar to
groovy 2.5.

When setting both "-Dgroovy.antlr4.cache.threshold=200" or
"-Dgroovy.antlr4.cache.threshold=600", it is slow: 1m 41s the first, and 1m
48s the second.

p

On Fri, Jan 17, 2020 at 10:11 PM Daniel.Sun <su...@apache.org> wrote:

> Here is the detailed result:
> results.zip <http://groovy.329449.n5.nabble.com/file/t340716/results.zip>
>
>
> Under Windows, we can set the JVM option by:
> set JAVA_OPTS=-Xms2g -Xmx2G -Dgroovy.antlr4.cache.threshold=600
>
> then run `groovy Parse.groovy 2` or `groovy Parse.groovy 4`
>
> Cheers,
> Daniel.Sun
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: RE: Groovy 3 very slow stub generation

Posted by "Daniel.Sun" <su...@apache.org>.

Here is the detailed result:
results.zip <http://groovy.329449.n5.nabble.com/file/t340716/results.zip>  

Under Windows, we can set the JVM option by:
set JAVA_OPTS=-Xms2g -Xmx2G -Dgroovy.antlr4.cache.threshold=600

then run `groovy Parse.groovy 2` or `groovy Parse.groovy 4`

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: RE: Groovy 3 very slow stub generation

Posted by Daniel Sun <su...@apache.org>.

I compared the time cost by antlr2 parser and Parrot parser via running the following script "Parse.groovy", which is placed under directory "nextflow-master\modules\nextflow\src\main\groovy\nextflow"[1]:

The heap size is set to 2G, i.e. "-Xms2g -Xmx2g"

1) run antlr2 parser
`groovy Parse.groovy 2`

cost 57.177s

2) run Parrot parser:
`groovy Parse.groovy 4`

As 364 groovy source files in all, we set threshold to 600 (> 364) to avoid cache being cleared
with "-Dgroovy.antlr4.cache.threshold=600": cost 58.672s    // almost same to antlr2 parser

without "groovy.antlr4.cache.threshold" setting: cost 67.183s

(Parse.groovy)
```
import groovy.io.FileType
import org.apache.groovy.parser.*

def parserVer = args[0]

def result = []
def parser = '4' == parserVer ? new Antlr4Parser() : new Antlr2Parser()
println "${parser.class} enabled!"

new File('.').eachFileRecurse (FileType.FILES) { file ->
  if (!file.name.endsWith('.groovy')) return
  
  println "Parsing $file"
  
  def b = System.currentTimeMillis()
  parser.parse(file)
  def e = System.currentTimeMillis()
  
  result << Tuple.tuple((e - b), file)
}

println "------------ RESULT --------------"
result.sort { o1, o2 -> o2.v1 <=> o1.v1 }.each {
	println "${it.v1 / 1000}s\t\t\t\t\t${it.v2}"
}

println "# ${result.sum { it.v1 } / 1000}s elapsed"

```


Cheers,
Daniel.Sun
[1] https://github.com/nextflow-io/nextflow/archive/master.zip

On 2020/01/17 18:08:22, "Daniel.Sun" <su...@apache.org> wrote: 
> If you find the performance issue is gone when you disable the Parrot parser
> with `-Dgroovy.antlr4=false`, you can try to enable the Parrot parser again
> and apply `-Dgroovy.antlr4.cache.threshold=200` shown as follows. 
> 
> ```
> compileGroovy {
>     groovyOptions.fork = true
>     groovyOptions.forkOptions.jvmArgs +=
> ["-Dgroovy.antlr4.cache.threshold=200"] // you can try to increase the
> threshold if your project contains many Groovy source files.
> }
> ```
> 
> The greater the value of threshold is, the longer the cache will be
> reused(i.e. not be cleared), but it will require bigger JVM heap. 
> 
> Note: antlr4 recommends never to clear the cache for better performance, but
> Parrot parser will clear the cache to avoid OOME when threshold reaches.
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> -----
> Apache Groovy committer & PMC member 
> Blog: http://blog.sunlan.me 
> Twitter: @daniel_sun 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>