[
https://issues.apache.org/jira/browse/GROOVY-12264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105095#comment-18105095
]
ASF GitHub Bot commented on GROOVY-12264:
-----------------------------------------
github-actions[bot] commented on PR #2795:
URL: https://github.com/apache/groovy/pull/2795#issuecomment-5307509935
### JMH summary — indy (commit `e336c06`)
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.927 × | 1.033 × | 99 |
| core | 2.710 × | 2.757 × | 83 |
| grails | 3.827 × | 3.796 × | 80 |
No benchmark is ≥1.5× slower than its 90-day baseline.
<sub>Runner calibration (this run vs baseline hardware): bench 0.91× (26
rulers) · core-ag 1.00× (3 rulers) · core-hz 0.96× (3 rulers) · grails-ad 1.06×
(3 rulers) · grails-ez 0.97× (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>
<!
> Optimize the unrelated-default-method scan during class generation
> ------------------------------------------------------------------
>
> Key: GROOVY-12264
> URL: https://issues.apache.org/jira/browse/GROOVY-12264
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> {{Verifier}} rejects a type that inherits two unrelated {{default}} methods
> of the same signature (GROOVY-10381, refined by GROOVY-11560). The scan runs
> in class generation for every type that lists two or more interfaces.
> Class generation is a large share of compile wall time. The scan must stay
> cheap on the common path, where there is no conflict.
> h3. Problem
> * Stream / {{flatMap}} allocation on every such type.
> * {{ClassNode.getAllDeclaredMethods()}} on the class and again on every
> interface. Each call rebuilds a full hierarchy method map and revisits
> inherited defaults.
> On a wide or deep interface DAG the second point is quadratic in the number
> of interfaces.
> h3. Approach
> * Walk each interface's own methods ({{getMethods()}}) with loops.
> {{getAllInterfaces()}} already includes super-interfaces, so each {{default}}
> is visited once.
> * Build the override-signature set only when two unrelated defaults actually
> collide, and only from the class plus its superclasses.
> * Avoid the {{Optional}} allocation in {{MethodNode.isDefault()}}.
> Before:
> {code:java}
> Set<String> declared = node.getAllDeclaredMethods().stream()
> .filter(m -> !m.isDefault())
> .map(MethodNodeUtils::methodDescriptorWithoutReturnType)
> .collect(Collectors.toSet());
> node.getAllInterfaces().stream()
> .flatMap(iface -> iface.getAllDeclaredMethods().stream())
> .filter(MethodNode::isDefault)
> .forEach(method -> {
> // conflict check
> });
> {code}
> After:
> {code:java}
> for (ClassNode iface : node.getAllInterfaces()) {
> for (MethodNode method : iface.getMethods()) { // this interface only
> if (!method.isDefault()) {
> continue;
> }
> // conflict check; collect overrides only on a real collision
> }
> }
> {code}
> Same conflict rules. No intended behaviour change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
