#[derive(PartialEq)] does not reorder field comparisons to improve performance

[Sol-Ell]

Summary

The #[derive(PartialEq)] macro currently compares fields in declaration order, which can lead to suboptimal performance when expensive fields (like references or slices) are compared before cheap fields (like scalars).

This can cause unnecessary memory comparisons (memcmp/bcmp) to run even when a cheap field would have determined inequality early.

---

Reproducible Example

#[repr(C)]
#[derive(PartialEq, Eq)]
pub struct StructA<'a> {
    field_1: &'a str, // expensive to compare
    field_2: u8,      // cheap
}

#[repr(C)]
#[derive(PartialEq, Eq)]
pub struct StructB<'a> {
    field_1: u8,      // cheap
    field_2: &'a str, // expensive
}

pub fn compare_a(a: StructA, b: StructA) -> bool {
    a == b
}

pub fn compare_b(a: StructB, b: StructB) -> bool {
    a == b
}

Generated Assembly

• compare_a compares the string (bcmp) before checking the u8.
• compare_b checks the u8 first and avoids bcmp on early exit.

See Godbolt for live comparison: https://godbolt.org/z/7a41eT3P3

---

Meta

• Rust version: stable (1.##) / nightly
• Affects #[derive(PartialEq)] macro
• Related: optimization of derived traits

[kupiakos]

gives the author clear control over the semantics of the comparison

The current documentation for derive(PartialEq) does not state the order in which the comparisons occur, unlike derive(PartialOrd). Also, neither of them state whether short-circuiting takes place. PartialEq only states that two structs are equal if their fields are equal. Depending on ordered comparisons (or short-circuiting) in the derive today for semantics is depending on an undocumented behavior and that should be avoided. Thus, changing it now would not be a major breaking change.

Besides, rustc doesn't even have enough information to figure out whether the comparison would be cheap or not

There's a pretty simple heuristic that'd cover many cases including this one: numeric primitives and references to them can be assumed to be cheaper to check than any other type. It's an optimization - it doesn't need to be perfect as long as it won't make things worse.

[moxian]

The current documentation for derive(PartialEq) does not state the order in which the comparisons occur, unlike derive(PartialOrd).

You are right, i managed to grossly misread the OP. My apologies.

[Sol-Ell]

I'm willing to take on this if no one else is working on it.