> I assumed the compiler might be able to optimize the extra check away if > the .next() method gets inlined, but not in the general case. Thus I was > trying to provide a general solution that wouldn't rely on back-end > optimizations. Are you saying I assumed wrong?
Optimization passes are almost all deterministic and predictable. The `inline` pass is guaranteed to inline any static call below the inline threshold that's not using C varargs, and the check *will* be eliminated when the `Option` representation is using a tag. When it's not using a tag, it may or may not be eliminated as LLVM doesn't have enough to go by without further external proof that the non-nullable pointer is really non-null. If the function is larger than the `inline` threshold, then I doubt there's a measurable performance issue from the branch. LLVM and the CPU will both predict a branch in a loop as not breaking out of the loop.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
