Cost of null references during runtime

Question

Are null reference exceptions expensive during runtime (do they cause lag)? I assume that these are handled by Unity, thus the nice debug message, but I was wondering if I should bother checking that certain references are not null before trying to carry out some action with them in order to improve performance, or would that be a waste of time?

For example, if I'm getting a component from a RayCastHit, should I bother checking that the hit is on a certain object that I know has the component, or should I even bother?

I know its as simple as adding something like

 if (someObject.GetComponent<someComponent>() != null){
      someObject.GetComponent<someComponent>().doSomething();
 }

but should I even bother, or just let Unity handle it?

Answer 1

Best Answer

Answer by fafase · Mar 09, 2015 at 12:50 PM

There is no concern to have on null checks, there are micro optimisation that will not affect your app in the end.

On the other hand, this could:

 someComponent comp = someObject.GetComponent<someComponent>();
 if (comp != null){
      comp.doSomething();
  }

in your case you are running GetComponent to check if the component is there and then you call it again to perform the action. In my case, I call once and do both actions.

Your game does not crash in Editor because Unity prints the debug and keeps going with some workaround, but if you run on device, it will most likely crash or freeze.

The short answer is "You HAVE to avoid null references".

Add comment · Show 6 · Share

Landern · Mar 09, 2015 at 12:56 PM 0

Share

or to look at it another way. If you're calling a friend to get a ride, should you call the friend, ask if their there, then hang up, call again and finally ask if you can get a ride?

Once you get a reference to the object, you don't need to call GetComponent over and over again as there is a cost associated with the look up for the component. As long as the scope doesn't change, you should be fine using the same reference over and over again as fafase illustrates above.

jakejolli · Mar 09, 2015 at 01:06 PM 0

Share

@Landern I think my question may have been misunderstood. I'm not asking how expensive it is to check if something is null, I'm asking how expensive it is to attempt to do something with a null reference (which might occur if I don't check for null.)

fafase · Mar 09, 2015 at 01:08 PM 0

Share

Well, you get a null reference exception and a crash of your app. So I don't know how much you value an unsellable app but that is what you get.

jakejolli · Mar 09, 2015 at 01:48 PM 0

Share

$$anonymous$$y game doesn't crash, I just get an error in my console... But I'm guessing that the short answer is: "Yes, you should avoid null references"?

fafase · Mar 09, 2015 at 01:51 PM 0

Share

Your game does not crash in Editor because Unity prints the debug and keeps going with some workaround, but if you run on device, it will most likely crash or freeze.

The short answer is "You HAVE to avoid null references".

Show more comments

Answer 2

Answer by HHess · Mar 01, 2019 at 10:24 AM

JetBrain's Ride warns using the null checks in 'performance critical context' https://github.com/JetBrains/resharper-unity/wiki/Avoid-null-comparisons-against-UnityEngine.Object-subclasses

Add comment · Show 1 · Share

Bunny83 · Mar 01, 2019 at 03:23 PM 1

Share

This should be considered a bug in the resharper. The custom == operator first does an actual null check on the managed side. Note that there is a huge difference if you run code inside the editor or in an actual build. For example inside the editor methods like GetComponent will always return an actual object in order to show a specialized error message. However in an actual build GetComponent will return null. An actual null value is treated perfectly well by the custom == operator. The only cases where it has an impact is when you actually destroyed an object where you still have a reference to. This will turn the object into a fake null object and may cause the == operator to actually check on the native side.

Though as you can see here if the reference is a $$anonymous$$onoBehaviour or a ScriptableObject this isn't really an issue.

Apart from that if you actually have situations where you can encounter null references you have to check for them, otherwise your application will just crash. The exact behaviour depends on the platform, but even if it doesn't crash it will throw an exception which is by far worse than having Unity check if the object is still alive. Note that Apple will reject any app that throws uncatched exceptions.

Cost of null references during runtime

2 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions