Paolo Di Tommaso

+1 for this. I think it would require to use the new module system and repackage it. Some info here https://stackoverflow.com/a/52645592

👍

I completely agree that a more generic mechanism would be better but that would require to wait for Groovy 3.0 (or later) that realistically wouldn't be released before 2019. For...

Not sure to understand with the length of the list should have an impact on the annotation overhead. That cost it's constant, isn't it?

OK, I've some numbers. I've made a poor man currentTimeMillis delta for different iterations and using a CompileStatic annotation. The results are these: **iteration**|**w/o annotation (ms)**|**with annotation (ms)**|**delta (ms)**| overhead...

I've never used jmh, but I can try to implement the benchmark with it if required. > You did something for toString() Not really, I've just copy&pasted the same code...

👍 On Feb 8, 2018 09:14, "Jochen Theodorou" wrote: > I think you misunderstood me a bit. toString is not a real problem. The > performance of equals is though....

Indeed. I'm starting to become e bit skeptic about this proposal. Surely it will add some overhead and since this is a critical code I agree that it should be...

Some progress here, I've made a JHM benchmark using the current groovy master. The benchmark class is [this](https://github.com/pditommaso/groovy/blob/d37d1ae3f5b5b4e63c658378fce3153b1794565f/subprojects/performance/src/jmh/java/org/apache/groovy/bench/ListBench.java), comparing default groovy equals, one using the proposed annotation and another using...

I've refined a bit the benchmark adding the a throughput mode that looks more informative. The benchmark test is [here](https://github.com/pditommaso/groovy/blob/jmh-list-equals-benchmark/subprojects/performance/src/jmh/java/org/apache/groovy/bench/ListBench.java). ``` Benchmark (size) Mode Cnt Score Error Units ListBench.equalsDefaultGroovy 1...