[
https://issues.apache.org/jira/browse/GROOVY-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573420#comment-17573420
]
Paul King edited comment on GROOVY-10709 at 8/1/22 6:51 AM:
------------------------------------------------------------
I did a quick prototype to see if there were any quick wins from tweaking our
current solution.
This was just for the "GroovyObjectHelper #findGetLookupMethod, #doLookup" part
which Jochen mentioned.
Java class looked like this:
{code}
public class Pojo1 extends GroovyObjectSupport {
@Override
public Object invokeMethod(String name, Object args) {
return Integer.valueOf(name.substring(1, 2));
}
}
{code}
Groovy code looked like this:
{code}
class Pogo1 {
@Override
Object invokeMethod(String name, Object args) {
assert name.size() == 2
name[1].toInteger()
}
}
{code}
Calling code looked like this:
{code}
@Benchmark
@Fork(value = 2)
@Measurement(iterations = 200, time = 1)
@Warmup(iterations = 20, time = 1)
static testCallGroovy3Classic() {
int result = 0
20.times {
for (obj in [new g3c.Pogo1(), new g3c.Pogo2(), new g3c.Pogo3(), new
g3c.Pogo4(), new g3c.Pogo5()])
for (method in ['m1', 'm2', 'm3', 'm4', 'm5'])
result += obj."$method"()
}
assert result == 1500
}
{code}
JMH results were:
{noformat}
3.0.12
Benchmark Mode Cnt Score Error Units
Main.testCallGroovy3Classic avgt 200 0.280 ± 0.002 ms/op
Main.testCallGroovy3Indy avgt 200 0.269 ± 0.002 ms/op
Main.testCallGroovy4 avgt 200 0.319 ± 0.001 ms/op
Main.testCallJavaImplementingGroovyObject avgt 200 0.273 ± 0.002 ms/op
4.0.4 (1-100 ~1ms, 101-200 ~0.6ms)
Benchmark Mode Cnt Score Error Units
Main.testCallGroovy3Classic avgt 200 1.627 ± 0.007 ms/op
Main.testCallGroovy3Indy avgt 200 1.585 ± 0.005 ms/op
Main.testCallGroovy4 avgt 200 0.558 ± 0.002 ms/op
Main.testCallJavaImplementingGroovyObject avgt 200 1.526 ± 0.005 ms/op
4.0.5-SNAPSHOT with metaclass respondsTo guard
Benchmark Mode Cnt Score Error Units
Main.testCallGroovy3Classic avgt 200 0.407 ± 0.005 ms/op
Main.testCallGroovy3Indy avgt 200 0.413 ± 0.007 ms/op
Main.testCallGroovy4 avgt 200 0.570 ± 0.005 ms/op
Main.testCallJavaImplementingGroovyObject avgt 200 0.370 ± 0.002 ms/op
{noformat}
The guard just checked using respondsTo:
{code}
if (groovyObject.getMetaClass().respondsTo(groovyObject,
"$getLookup").isEmpty()) return null;
{code}
This is a very preliminary microbenchmark but from initial results, it seems
worth trying this in a snapshot.
was (Author: paulk):
I did a quick prototype to see if there were any quick wins from tweaking our
current solution.
This was just for the "GroovyObjectHelper #findGetLookupMethod, #doLookup" part
which Jochen mentioned.
[DELETED I am preparing a bigger test]
> Performance regression in Gradle with Groovy 4
> ----------------------------------------------
>
> Key: GROOVY-10709
> URL: https://issues.apache.org/jira/browse/GROOVY-10709
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.3
> Reporter: Kyle Moore
> Priority: Major
> Attachments: test-results-largeAndroidBuildPerformanceAdHocTest.zip
>
>
> The Gradle team is exploring Groovy 4 as the included version for our next
> major release.
> Our initial performance tests show a significant regression which may be
> caused by excessive method calls to generate specialized exceptions that
> don't have stacks.
> I will attach a tome of performance data comparing Gradle built with Groovy
> 3.0.11 vs. 4.0.3. Interesting measurements are available at:
> *
> run-help/7.6-20220727093039+0000/diffs/run-help-7.6-20220727093039+0000-vs-7.5-cpu-simplified-backward-diff-flames.svg
> * performance-tests/report/index.html -> comparing "Gradle 7.5" vs. "Current
> Gradle" shows a significant regression.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
