comparison_chain suggestion can be a performance regression

[sourcefrog]

clippy 0.0.212 (23549a8 2020-03-16)
rustc 1.44.0-nightly (f509b26 2020-03-18) on macos

clippy suggests rewriting some chained if/else blocks in my code, like so

-    let y = l[0];
-    if y > x {
-        return 0;
-    } else if y == x {
-        b = 0;
-    } else {
-        a = 1;
-        c = 1;
-    }
+    match l[0].cmp(&x) {
+        Ordering::Greater => return 0,
+        Ordering::Equal => b = 0,
+        Ordering::Less => {
+            a = 1;
+            c = 1;
+        }
+    };

This is semantically the same and arguably cleaner. But, according to a Criterion microbenchmark, Clippy's suggestion is significantly slower than the chained comparisons.

It looks like this might be related to the simple comparison being inline, versus the cmp remaining as

    call    core::cmp::impls::<impl core::cmp::Ord for i32>::cmp

Probably in many cases the performance difference isn't noticeable and it's better style, but perhaps there should at least be a caveat in the Clippy docs.

(Also, ideally the compiler should be smart enough to make it just as fast.)

[xtqqczze]

#6390 did not fix this issue, it only flagged it in the documentation.

@sourcefrog is there still a performance regression with latest rustc?

[xtqqczze]

    call    core::cmp::impls::<impl core::cmp::Ord for i32>::cmp

Looks like this is still an issue: goldbolt.org

[scottmcm]

That godbolt link doesn't run the optimizer, so of course it's different, but isn't relevant. If worse perf in debug was a reason to not lint, then all the "use an iterator" lints would have to be removed too.

Here's a better link: https://godbolt.org/z/6dP4je7Eb

Looks like LLVM's middle-end optimizes that perfectly well -- it gives exactly the llvm.ucmp.i8.i8 intrinsic and the switch as you'd expect -- but LLVM's x64 backend doesn't optimize it as well as it could. You might want to file an LLVM issue about it.