Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsEquals/HashCode Generator sorting fields
https://www.eclipse.org/forums/index.php/mv/msg/416211/959255/#msg_959255
I guess that it would be nicer when the code first checks primitive types (java.lang) then complex types, and then arrays (or Iterables - if possible).
This might help to avoid deep tree traversals when first checking an equal complex field type before checking the (for example) name field value of the object that does not match.
This might help improving the performance for applications with a lot of "contains"-operations and big tree-like objects]]>Andre Albert2012-10-26T15:18:37-00:00Re: Equals/HashCode Generator sorting fields
https://www.eclipse.org/forums/index.php/mv/msg/416211/961761/#msg_961761
Andre Albert wrote on Fri, 26 October 2012 17:18
I guess that it would be nicer [...]
This might help to avoid deep tree traversals when first checking an equal complex field type before checking the (for example) name field value of the object that does not match.
This might help improving the performance for applications with a lot of "contains"-operations and big tree-like objects
Do you have any performance figures backing this claim? Otherwise it sounds a bit like speculative optimization, s.t. JDT should not get involved with, IMO.
Think of it this way: what are the odds that a big tree-like object structure is infact equal while a direct field (like "name") differs? If all criteria must be fulfilled for "equals", do you know which comparisons are more likely to allow an early "return false"?