Mutable structs with all constant fields outperform immutable structs for equality comparison

nsajko · December 4, 2024, 12:13am

You didn’t define == for the new types, though. The default == method just forwards to ===:

julia> struct S end

julia> @which S() == S()
==(x, y)
     @ Base Base.jl:207

So it comes down to === being cheaper for the mutable struct, because it’s implemented as a simple integer comparison, unlike for the immutable struct, where the === is recursive. This is documented, the doc string of === starts with:

Determine whether x and y are identical, in the sense that no program could distinguish them. First the types of x and y are compared. If those are identical, mutable objects are compared by address in memory and immutable objects (such as numbers) are compared by contents at the bit level.

Regarding the unfortunate default method of ==, here are some Github issues:

github.com/JuliaLang/julia

Type-safe equality operators

opened 12:05AM - 05 May 21 UTC

jtrakk

breaking equality

I often make mistakes by using `==` between two objects that I shouldn't be comp…aring, such as comparing a number to an array of numbers or comparing a string to a character. The `==` comparison evaluates to `false`, but it wasn't the comparison I meant to make. For example, ```jl a = [1,2,3] b = 5 if a == b; # evaluates to false ``` I wish there were an equality-checking operator that would give an error for incompatible types, like in the example above. I'm not sure if the right implementation would be - check if they have exactly the same type - check some `<:` subtyping relationship - check if they can `convert` into each other's types - check if they can `promote` into a shared type or something else, or multiple different operators for different purposes. There are plenty of equals-like operators in unicode (eg ≟, ≐). Regardless, the current situation where my mistakes result in silent `false`s causes me problems too often for comfort; I would much rather get an explicit error that I can correct. What would be a good solution here?

The behavior is documented, though, the == doc string starts with:

Generic equality operator. Falls back to ===.

Topic		Replies	Views
Why using a mutable struct type argument to create instances creates a 50x slowdown? Performance question , type , function	7	522	June 25, 2023
Mutable ProtoStruct beats Base Mutable Struct in microbenchmark...and then it is much slower in real program Performance question , package , benchmark	9	364	November 9, 2023
Optimising function with const instead of struct? Performance	9	737	July 7, 2018
Container of mutable structs without 100x slowdown? Performance struct , accessors	7	1167	September 1, 2022
Situations where mutable struct is more performant than immutable struct Performance	6	915	October 5, 2019

Mutable structs with all constant fields outperform immutable structs for equality comparison

Related topics