#[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

[moxian]

The current behavior is desirable, as it gives the author clear control over the semantics of the comparison, which is often more important than the performance. Changing it now would be a major breaking change. (And I don't believe the performance gains are even noticeable, although it would be interesting to test).

Besides, rustc doesn't even have enough information to figure out whether the comparison would be cheap or not. &str comparison might be "expensive" because it's a slice, but is String comparison expensive? We can't know because String has a custom non-derived PartialEq implementation.
And if we treat all custom PartialEq implementation as "expensive" then that defeats the point of reshuffling, since people are now encouraged to avoid derive(PartialEq) if they ever rely on specific ordering for semantics reasons (which means that there are fewer opportunities to insert the reshuffling)

@rustbot label: +C-discussion

[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.