[ 
https://issues.apache.org/jira/browse/GROOVY-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114017#comment-18114017
 ] 

ASF GitHub Bot commented on GROOVY-12398:
-----------------------------------------

github-actions[bot] commented on PR #2921:
URL: https://github.com/apache/groovy/pull/2921#issuecomment-5625032608

   ### JMH summary — indy (commit `1dfc0e3`)
   
   Speedup vs trailing 90-day baseline on gh-pages. Higher = faster.
   `1.00` = in line with history. Per-benchmark ratio, geomean within group.
   Time-per-op units inverted so direction is consistent. The *calibrated*
   column divides out this runner's speed vs the baseline hardware, as
   measured by Groovy-independent pure-Java ruler benchmarks.
   
   | Group  | Speedup | Calibrated | n |
   |--------|---------|------------|---|
   | bench | 1.054 × | 1.118 × | 124 |
   | core | 4.284 × | 4.554 × | 108 |
   | grails | 2.865 × | 3.022 × | 80 |
   
   > ⚠️ **2 benchmarks at least 1.5× slower than the 90-day baseline:**
   > - `org.apache.groovy.bench.AryBench.groovyCS ( {"n":"1000"} )` — 2.30× 
slower (calibrated)
   > - `org.apache.groovy.bench.AryBench.groovyCS ( {"n":"1000000"} )` — 1.98× 
slower (calibrated)
   
   <sub>Runner calibration (this run vs baseline hardware): bench 0.97× (27 
rulers) · core-ag 0.94× (3 rulers) · core-hz 0.93× (3 rulers) · grails-ad 0.97× 
(3 rulers) · grails-ez 0.93× (3 rulers)</sub>
   
   <sub>Baseline: <code>dev/bench/jmh/&lt;part&gt;/indy/data.js</code> on 
gh-pages, trailing 90 days. <a 
href="https://apache.github.io/groovy/dev/bench/jmh/summary.html";>Daily 
dashboard</a> · <a 
href="https://apache.github.io/groovy/dev/bench/jmh/";>Per-suite raw 
data</a></sub>
   
   <!

> Improve lexer and parser performance
> ------------------------------------
>
>                 Key: GROOVY-12398
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12398
>             Project: Groovy
>          Issue Type: Improvement
>            Reporter: Daniel Sun
>            Priority: Major
>
> The Groovy ANTLR4 grammar already uses left-recursive expressions, which is 
> the main idea of the [optimized Java 
> grammar|https://github.com/antlr/grammars-v4/tree/master/java/java]. Several 
> remaining lexer and parser costs still match patterns that grammar was 
> written to avoid.
> h3. Problem
> * Number literals are assembled from a chain of one-character fragments 
> ({{Digit}}, {{Zero}}, {{NonZeroDigit}}, ...). The invalid-octal alternative 
> also counts digits in a mid-rule action loop, which prevents DFA compilation 
> of {{IntegerLiteral}}.
> * Every identifier, including ASCII names such as {{Foo}} and {{foo}}, 
> evaluates {{Character.isUpperCase}} to choose {{CapitalizedIdentifier}} vs 
> {{Identifier}}.
> * GString and comment predicates ({{isFollowedByJavaLetterInGString}}, 
> {{isFollowedByWhiteSpaces}}) allocate a one-character {{String}} and run 
> {{Pattern.matcher}} on each lookahead.
> * {{elementValues}} is ambiguous with assignment: {{@Foo(a = 1)}} can be 
> named pairs or an assignment expression, so {{AdaptivePredict}} explores both 
> (see [antlr/grammars-v4#215|https://github.com/antlr/grammars-v4/issues/215]).
> h3. Approach
> Keep token types and language semantics unchanged.
> * Flatten number and float fragments to character classes, as in the 
> optimized Java lexer. Validate invalid octal once at the end of the 
> alternative.
> * Split ASCII identifiers on a predicate-free DFA path: uppercase {{A-Z}} 
> becomes {{CapitalizedIdentifier}}; {{a-z}}, dollar and underscore become 
> {{Identifier}}. Unicode still uses predicates.
> * Replace the regex-based predicates with direct character tests.
> * Gate {{elementValue}} with {{!isIdentifierAssign(_input)}}, the same idea 
> as Java's {{IsNotIdentifierAssign}}.
> h3. Result
> Local parse-only measurement (SLL then LL) of {{src/main/groovy}} + 
> {{src/test-resources/core}} (245 files, approximately 570k characters):
> ||Run||Best||Mean||
> |before|0.231s|0.401s|
> |after|0.146s|0.169s|
> Best run is about 1.6x faster. Mean improves more because prediction is more 
> stable after DFA warmup.
> Related: GROOVY-10454, GROOVY-9588



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to