[
https://issues.apache.org/jira/browse/GROOVY-12173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097279#comment-18097279
]
ASF GitHub Bot commented on GROOVY-12173:
-----------------------------------------
github-actions[bot] commented on PR #2720:
URL: https://github.com/apache/groovy/pull/2720#issuecomment-5011051820
### JMH summary — indy (commit `a931ddd`)
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 | 0.996 × | 0.998 × | 84 |
| core | 3.930 × | 4.176 × | 77 |
| grails | 2.274 × | 2.225 × | 80 |
<sub>Runner calibration (this run vs baseline hardware): bench 1.00× (26
rulers) · core-ag 0.92× (3 rulers) · core-hz 0.97× (3 rulers) · grails-ad 0.97×
(3 rulers) · grails-ez 1.06× (3 rulers)</sub>
<sub>Baseline: <code>dev/bench/jmh/<part>/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>
<!
> Left-factor parser rules to reduce lookahead on hot parse paths
> ---------------------------------------------------------------
>
> Key: GROOVY-12173
> URL: https://issues.apache.org/jira/browse/GROOVY-12173
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> h3. Motivation
> Successful parse cost in the ANTLR4 (Parrot) parser is dominated by adaptive
> prediction. Several grammar rules still force the simulator to explore
> *sibling alternatives that share a long common prefix*, or to re-run an
> expensive semantic predicate that was already evaluated. That inflates DFA
> growth and SLL work even when the input is valid.
> This improvement left-factors and simplifies a small set of
> non-left-recursive rules so decisions commit earlier, *without* changing
> language semantics or the AST shapes {{AstBuilder}} relies on.
> h3. Changes
> *1. {{importDeclaration}} — left-factor {{annotationsOpt IMPORT}}*
> ** Before: two alternatives both started with {{annotationsOpt IMPORT}}, so
> prediction replayed the shared prefix to choose module vs ordinary import.
> ** After: one {{IMPORT}}, then {{MODULE qualifiedName}} vs {{STATIC?
> qualifiedName ...}}. Decision is effectively one token after {{IMPORT}}.
> *2. {{typeNamePairs}} — left-factor {{LPAREN}} / {{RPAREN}}*
> ** Before: two alternatives both wrapped the list in parentheses (positional
> multi-assign vs GEP-20 keyed pairs).
> ** After: open paren once; choose {{typeNamePair}} vs {{keyedPair}} (keyed
> form distinguished by {{COLON}}).
> *3. {{pathElement}} — left-factor {{DOT}}*
> ** Before: {{DOT nls NEW creator}} and {{DOT nls namePart}} were separate
> alternatives, both starting with {{DOT}}, so every property access paid for
> exploring both.
> ** After: {{DOT nls}} then {{NEW creator}} vs name selection. After {{DOT}},
> {{NEW}} is LL(1). Non-DOT selectors ({{?.}}, {{*.}}, {{??.}}, {{.&}}, {{::}})
> stay separate.
> *4. {{blockStatement}} — drop redundant local-variable alternative*
> ** Before:
> {noformat}
> blockStatement
> : localVariableDeclaration
> | statement
> ;
> {noformat}
> ** {{statement}} already includes {{localVariableDeclaration}}
> ({{#localVariableDeclarationStmtAlt}}). Inside a block, command-style calls
> such as {{foo bar}} therefore evaluated {{isInvalidLocalVariableDeclaration}}
> *twice* (fail on the first alt, fail again via {{statement}}).
> ** After: {{blockStatement : statement}} only. Observationally equivalent;
> halves predicate traffic on that path.
> ** {{AstBuilder#visitBlockStatement}} updated to visit {{statement}} only.
> h3. Non-goals / deliberate non-changes
> * Do *not* left-factor the three {{#relationalExprAlt}} alternatives under
> left-recursive {{expression}} into one subrule group. ANTLR's left-recursion
> rewriter only preserves operator precedence for direct {{expression OP
> expression}} forms; factoring the operator into a parenthesised group lets
> {{right=expression}} accept lower-precedence ops (e.g. {{&&}}), so {{x >= min
> && x <= max}} can parse as {{x >= (min && ...)}} and break type checking.
> * Index vs named property args ({{indexPropertyArgs}} /
> {{namedPropertyArgs}}) still share {{SAFE_INDEX|LBRACK}}; merging them would
> reshape the CST and force a larger {{AstBuilder}} change for limited gain —
> left for a follow-up if measured.
> h3. Compatibility
> * Language surface and AST construction paths are unchanged for correct
> programs.
> * No public API additions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
