[
https://issues.apache.org/jira/browse/GROOVY-12285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106884#comment-18106884
]
ASF GitHub Bot commented on GROOVY-12285:
-----------------------------------------
github-actions[bot] commented on PR #2823:
URL: https://github.com/apache/groovy/pull/2823#issuecomment-5379787462
### JMH summary — indy (commit `791b2f6`)
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.961 × | 1.001 × | 99 |
| core | 2.973 × | 2.596 × | 83 |
| grails | 4.234 × | 4.240 × | 80 |
No benchmark is ≥1.5× slower than its 90-day baseline.
> ⚠️ Runner speed differs ≥15% from the historical baseline hardware for:
core-hz. Raw speedups are not meaningful for those parts — use the calibrated
column.
<sub>Runner calibration (this run vs baseline hardware): bench 0.96× (26
rulers) · core-ag 1.11× (3 rulers) · core-hz 1.19× (3 rulers) · grails-ad 1.06×
(3 rulers) · grails-ez 0.95× (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>
<!
> STC: index extension methods by name and skip cloning non-generic parameters
> ----------------------------------------------------------------------------
>
> Key: GROOVY-12285
> URL: https://issues.apache.org/jira/browse/GROOVY-12285
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> The static type checker resolves DGM (Default Groovy Methods) and other
> extension methods by walking the receiver hierarchy and collecting methods of
> a given name. {{ExtensionMethodCache}} stores a flat list per receiver type,
> so each named lookup scans every method on that type. Receivers such as
> {{Object}} and {{Collection}} have hundreds of DGM methods, and that scan
> sits on the compile hot path.
> {{chooseBestMethod}} erases generic parameter types before measuring
> argument-parameter distance. It currently clones every candidate's parameter
> array to do so, including methods that have no generic parameters.
> h3. Proposed change
> * When a class loader's extension methods are scanned, index each receiver
> list by method name so a named lookup is a hash get rather than a linear scan.
> * Clone a candidate's parameter array only when at least one parameter is a
> generics placeholder or otherwise uses generics.
> * Drop derived indexes together with the loader's method map so they cannot
> go stale independently.
> {code:java}
> // today
> for (MethodNode node : fromDGM) {
> if (node.getName().equals(name)) accumulator.add(node);
> }
> // proposed
> accumulator.addAll(EXTENSION_METHOD_CACHE.get(loader, className, name));
> {code}
> h3. Impact
> Compile-time only. Named lookup results and overload selection stay the same.
> {{MethodNode}} parameter arrays are not mutated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
