[Caml-list] Performance degradation when using '=' instead of 'compare'

[Caml-list] Performance degradation when using '=' instead of 'compare'

[Leonardo Laguna Ruiz]

I don't know if this has been discussed before, but a few weeks back we 
detected a large performance degradation in our product. We tracked down 
the problem and turned out to be that an innocent looking line was 
changed. Something like this:

if compare a b = 0 then  .... else ...

became:

if a = b then ... else ...

in our specific algorithm, 'a' and 'b' where values of some custom type. 
By looking at the ocaml runtime code we could see that 'compare' 
performs physical equality before doing the structural comparison.  
While '=' only performs structural equality.  In our case, 'a' and 'b' 
were most of the times physically equal, and by changing to the operator 
'=' a full structural comparison of the object was performed.

I wonder what's the reason why '=' does not uses physical equality. Now 
we are trying to track all the places where '=' is used and changing it 
to either:  "a == b | a=b", or "compare a b = 0"

Leonardo

Re: [Caml-list] Performance degradation when using '=' instead of 'compare'

[octachron]

The non-reflexivity of floating point equality is responsible for this 
problem. Since NaN ≠ NaN, (=) cannot use physical equality as a 
shortcut. For instance, with

let x = [1, [0. /. 0.]]

(x = x) is false, even if (x == x) is true.

Compare is not subject to this semantic for floating point equality and 
can therefore use physical equality as a shortcut.

See also https://caml.inria.fr/mantis/view.php?id=7502 for another 
instance of this problem in the context of cyclic data structure.

— octachron.