[
https://issues.apache.org/jira/browse/GROOVY-12288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106965#comment-18106965
]
ASF GitHub Bot commented on GROOVY-12288:
-----------------------------------------
github-actions[bot] commented on PR #2825:
URL: https://github.com/apache/groovy/pull/2825#issuecomment-5381776415
### JMH summary — indy (commit `4947fc8`)
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 | _no overlap with baseline_ | — | 0 |
| core | 9.316 × | 9.184 × | 83 |
| grails | 4.090 × | 3.770 × | 80 |
No benchmark is ≥1.5× slower than its 90-day baseline.
<sub>Runner calibration (this run vs baseline hardware): core-ag 0.96× (3
rulers) · core-hz 1.08× (3 rulers) · grails-ad 1.06× (3 rulers) · grails-ez
1.10× (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>
<!
> Cache ClassWriter getCommonSuperClass lookups per class
> -------------------------------------------------------
>
> Key: GROOVY-12288
> URL: https://issues.apache.org/jira/browse/GROOVY-12288
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> Bytecode generation uses an ASM {{ClassWriter}} with {{{}COMPUTE_FRAMES{}}}.
> Frame computation calls {{getCommonSuperClass}} at every control-flow merge.
> Groovy overrides that method so types still being compiled are resolved
> through {{ClassNode}} ({{{}CompileUnit{}}}, generated inner classes,
> {{{}ClassNodeResolver{}}}) rather than {{{}Class.forName{}}}.
> {{COMPUTE_FRAMES}} asks for the same binary-name pairs many times inside one
> class. Each call converts slashes to dots, resolves two \{{ClassNode}}s, and
> walks superclasses with isDerivedFrom. Class generation is about half of
> compile wall time.
> h3. Approach
> Memoize both steps on the {{ClassWriter}} created by
> {{{}CompilationUnit.createClassVisitor{}}}. One writer is allocated per
> generated class and discarded afterwards, so the maps cannot go stale across
> classes.
> ||Cache||Key||Value||
> |{{classNodeByName}}|binary name (dot form)|{{ClassNode}} (successful lookups
> only)|
> |{{commonSuperByPair}}|canonical pair of internal names|internal name of the
> common superclass|
> The key is order-independent: {{(A,B)}} and {{(B,A)}} share one entry. The
> common-superclass algorithm is unchanged.
> h3. Impact
> Compile-time only. {{getCommonSuperClass}} results and generated bytecode
> stay the same.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)