koobas.hobune.stream
Unity Engine conditional comparison sign evaluation - is exact evaluation more taxing?
When you are just checking for a flip, such as var isTurnedOn = 1; or 0 if not, is it better to use
if(isTurnedOn==1) or if(isTurnedOn>0)
Is it actually more taxing on the compiler if it's checking for an exact match, rather than an entire range (such as greater than or less than)
okay... why the downvote. this isn't posted in the manual or in google and i'm sure i'm not the only one who wonders if just changing some of my ='s to > signs could help.
What would be better is using true/false ins$$anonymous$$d of numbers. Not from a performance standpoint (syclamoth is right that any possible speed difference is infinitesimal or nonexistant), but from a logic standpoint.
Believe it or not, one reason why I asked this question was because a (pure) mathematician took a look at my code and suggested that I change a gazillion references of exact integer comparisons to > than's. I think rabbitfang's answer below explains how computing works differently due to the bit-comparison stuffs.
Although I wonder if the added higher level stuff through c# and unity and such changes how the evaluation works...
There's no reason to use > ins$$anonymous$$d of ==, if == is appropriate. That is not the sort of thing you should change. If it makes sense to use > because it would make the code more understandable, then yes, but that's not an "optimization" that you should ever use.
This is from what I learned from quick research on the Internet
From a native-code perspective (code like C/C++, not C#), the equality operator and the greater than operator would consume the same number of operation codes (only one). How this relates to actual speed, I do not know.
From a bit-comparison standpoint, the equality operator will be faster as only a bitwise AND operation would need to be performed on the value, where the comparison would be more complex.
From a programming standpoint, if a variable will only contain a yes/no, 1/0, true/false value, it would be better to use a boolean variable, which (in theory), would be faster than integer comparison (equality or inequality); also, because the variable is prefixed with is, by convention it should be a boolean.
If you know for certain that the value will never be either 1 or 0, then I would use ==. If it is possible for it to be a value other than 1 or 0 (or just for safety), I would use != 0 or == 0.
To answer the question, there is no noticeable difference within Mono (.NET implementation). If you have performance critical code that requires as much speed as you can muster, you should be using plugins.
P.S. "taxing on the compiler" is asking about when you build your project, not when it is running.
What is it called when it's running (on mobile) - taxing on the runtime player?
Just 'taxing'. There are lots of other words/phrases, like "expensive" or "resource intensive".
How about just "slow"? We know you are talking about runtime because who cares if it compiles fast or not.
Unfortunately, this question is far too low-level to be answered sensibly here. It depends on the platform and the specific assembly methods, and in the end the difference is probably too tiny to measure anyway... It's probably better to use whatever makes the most sense logically, because it's better to have code that is easier to debug than to have code that is a tiny hundredth of a percentage faster.
well, some general best practice could help or some understanding of how Unity treats conditionals, since it's very simple to just change some comparison signs to > ins$$anonymous$$d of = (but is it actually better, or the other way around?)... not sure why that deserves a downvote
I didn't downvote it. I don't think it's a bad question, I just don't think it's a relevant question. I think that it's not something that Unity necessarily has any say in- such a low-level operation really depends on specifics in how the program is implemented in the hardware it is running on, and that isn't something you can ever predict. Look it up on Google or StackOverflow for a more in-depth answer.
actually, doesn't it also depend on how unity compiles it to bytecode?
To a certain extent, yes, but this also depends on the platform and specific hardware implementation of said bytecode. I stand by my original statement.
