Basically the title.
Would it be worth it to convert all my
if(object)
{
//Do Stuff
}
To
if(boolean == true)
{
//Do Stuff
}
?
Depends on how often you call it. If it’s only a single time or even in Update, don’t even bother. If you’re calling it million times a frame though, that might be something to consider…
Do not worry about that, its not something that could impact performance. its basically calling a method, which is probably inline so you shouldnt worry
Well, I AM calling it millions of times per frame… should I change it?
An object can be any random size, whereas a bool is only a single byte in size. So if you’re calling it that much then yes, a bool is better for performance.
The size has nothing to do with this whatsoever. Also, it’s size of the reference that matters, not the size of the object, and references are always the same size (which may even be the same size as a bool).
It all comes down to what happens in Unity’s overloaded “==” operator for their objects. But I strongly suspect that it’s a check against an internal bool anyway. I honestly wouldn’t worry about it. This isn’t the kind of optimisation I’d recommend since it’ll make your code more complex/harder to maintain for probably no practical benefit.
Taking a step back, what is this actually for? You’re checking if an object exists. Why not just remove it from the collection when it’s destroyed, and thus not need to check at all? Or consider other approaches to the issue so that you’re not checking a list for being littered with nulls as you use it.
Thank you. Exactly the answer I was looking for.
I need this for a pathfinding algorithm. Each node in the graph has references to each of it’s 8 neighbors (saved in 8 separate variables, one for each of the 8 directions). I’m just checking to see if said neighbors exist. I’ve managed to chop the pathfinding time down to less than a millisecond, which is why I’m trying to find tiny optimizations like this.
In that case, since it is indeed a micro-optimisation that you want, test it.
It depends on how much stuff that Object.Equals - as in, the Object that is the base class of everything - has been overridden and thus forced to check.
That’s why, if you ever benchmark an integer against a string, the int will generally be faster; an int is 32 bits, while a string is a variable number of 2-byte characters. For a string to be equal to another string, each character must match; conversely, for ints to match bits have to be in a matching sequence. One of those is smaller than the other!
For your specific question, I would be more than willing to wager that bool - AFAIK a 1-bit value - would be significantly faster to perform an equality check on than UnityEngine.Object.
Useful info: http://msdn.microsoft.com/en-us/library/ms173147(v=vs.80).aspx
Equality checks don’t necessarily work like that at all, though. For starters, plenty of equality checks look at references rather than the contained data (and this includes strings at least some of the time).
Secondly, a bool can indeed be represented by one bit, but that’s not necessarily how it’s stored, and it’s not at all how memory is accessed.
Third, memory access time often far outweighs actual check or calculation time. So it can be faster to do calculations or checks that take more CPU time if doing so saves you from additional memory access. (This is why rearranging how things are laid out in memory can sometimes get you better performance gains than optimising algorithms or calculations.)
Also, don’t jus think about the check itself. Think about what has to happen both when it passes and fails, and the resulting overall workload.
This could all swing both ways, and may be dependent on the target platform. So the only real answer is to test it.
Well, I DO know that comparing if two objects are equal to each other is slow as molasses. I give them each unique ID numbers, and just check those.
That said, in this scenario, I’m just checking to see if an object exists, so it’s not relevant in this case.
I did switch to using booleans a couple hours after posting this. Looking at the profiler, I couldn’t really determine much of a difference (although, if anything, using booleans was slower). I switched back, and forgot to take screenshots of the profiler, though, so I can’t post the raw numbers here.
Wouldn’t if(object) be an implicit downcast to a boolean which, in the case of UnityEngine.Object, does a != null check (AFAIK anyway - I had always assumed they did that to mimic JS behavior)? If that is the case, might it not be faster to simply do the null check yourself?
This… kind of.
if(object) doesn’t cast anything down to a Boolean. It just checks to see if the object exists, it’s equivalent to using “object == null” or ReferenceEquals(object, null); However, that only holds true for reference types. If “object” was actually a value type such as a string it wouldn’t work. In your case though, since you’re talking nodes and node neighbors I’m assuming you’re using class objects (reference types) so if(object) would be fine.
In terms of performance… it’s an equality operator that will only result in a single line of IL code being generated and whereas it’s just checking the reference equality to null it’s not going to perform any worse than doing the bool check. Both are going to do the same thing and generate essentially the same IL. It will check the bool value against true / false or it will check the object reference against null.
Since this is a reference test and not a value comparison, leave it as is, though I would recommend rewriting it for readability to something like:
if(object == null)
or
if(ReferenceEquals(object, null))
Thanks for clarifying. I had assumed that creating an implicit operator overload would be doing some kind of cast but after some reading it appears to just be another method call in this case (since no cast actually occurs).