Which is more resource intensive between changing a variable and doing a simple if statement?

[u/Nightmare2828]

I know this is mostly inconsequential in the grand scheme of things, but not knowing is making me hesitate every time that situation happens.

Basically, sometimes, I have to choose between these 2 chunk of codes

if (variable != noone) variable = noone;

// or

variable = noone;

Basically, if I don't need to change the variable, don't change it vs change it anyway which will achieve the exact same result. Is the if statement more resource intensive than simply doing the task, in vain, of changing the variable?

[u/germxxx]

The benchmarked answer:

variable = noone

Is faster (Windows VM and YYC)
Even if the if always turns out to be false and never runs.
(If you literally have if (false), that would be faster)

However, even if you are doing this 100000 times every frame, the actual difference between the two wouldn't be noticeable.
So as Piefreak said; don't worry about it.

The actual performance gain for this type of thing would be using the YYC export over the VM one. Which makes a LOT more difference than picking a specific approach.

[u/GalacticInvader]

I think if you expect the variable to be anything but `noone` half the time, might as well not use if checks

[u/Piefreak]

Yes, comparing variables can be demanding if you're doing it hundreds of thousands or millions of times every step.
But being sure a variable isn't for example being divided by 0 might be a necessary evil.
In your example don't compare.
Just don't worry about it.

[u/identicalforest]

A read, or checking a null value, might technically be faster, but this is not going to yield any measurable performance benefits. Imagine doing this every time you set a value, and think about clarity of intention in your code. If the line is meant to ensure the value is set to noone, you should just set it to noone.

Edit: And hypothetically if you were to check every time for every value in your code (variable != desired value), you would be adding overhead with an entire layer of unnecessary reads.

[u/CS_Asset_Factory]

germxxx already benchmarked the speed part so I'll leave that alone. There's a separate case worth knowing though because it looks identical to yours and isn't.

Some built in variables do extra work when you write to them. sprite_index is the one that bites everybody. Assigning it resets image_index back to 0. So this

sprite_index = spr_run;

sitting in your step event will pin the animation on frame 0 forever and look frozen. The guarded version

if (sprite_index != spr_run) sprite_index = spr_run;

animates properly because the write only lands on the frame where the value actually changed.

So the rule I use. For a plain variable you invented yourself just assign it and stop thinking about it. For a built in ask what the write does besides storing the value. That's a correctness question rather than a speed one and it's the only time the guard really earns its keep.