equals/hashCode/toString implementation

forax at univ-mlv.fr forax at univ-mlv.fr
Fri Jan 10 11:14:00 UTC 2020


> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 9 Janvier 2020 16:07:50
> Objet: Re: [records] Record updates for Preview/2

>> - @Deprecated on record components

> Please outline what you think we want on a separate thread?

>> - change the bootstrap method protocol (a little bit)

> Let's start a thread on this too.

>> - equals/hashCode implementation are currently slooooow

> Can you qualify/quantify "slow"?
sure ! 
toString is very very very slow, equals can be a little bit faster, hashCode has no issue. 

Using this benchmark [1]: 
Benchmark Mode Cnt Score Error Units 
ObjectMethodsBenchMark.equals_class avgt 5 67.953 ± 0.145 ns/op 
ObjectMethodsBenchMark.equals_record avgt 5 70.654 ± 0.154 ns/op 
ObjectMethodsBenchMark.hashCode_class avgt 5 2.741 ± 0.002 ns/op 
ObjectMethodsBenchMark.hashCode_record avgt 5 2.288 ± 0.002 ns/op 
ObjectMethodsBenchMark.toString_class avgt 5 20.381 ± 0.066 ns/op 
ObjectMethodsBenchMark.toString_record avgt 5 713.522 ± 14.290 ns/op 

- toString currently uses String.format() so it's dog slow. 
Wiring the bootstrap method to use the StringConcatFactory will fix the issue. 

- equals doesn't test primitive first so it's just a little bit slower that if I write it by hand 
So it's not slow compared to any code generated by an IDE or things like Lombock but it can be faster. 
Sorting the record components to have the 32 bits primitive types tested first (so create the corresponding guardWithTest last) is the usual trick. 
Rémi 

[1] [ https://github.com/forax/amber-record/blob/master/src/test/java/fr.umlv.record/fr/umlv/record/ObjectMethodsBenchMark.java | https://github.com/forax/amber-record/blob/master/src/test/java/fr.umlv.record/fr/umlv/record/ObjectMethodsBenchMark.java ] ] 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200110/91703989/attachment.htm>


More information about the amber-spec-experts mailing list