Do editor errors affect device performance?

Here are my tips for how to handle errors before release.

Tip.1: If your game is trowing NullReferenceException's during runtime. Fix them. Fix all of them. Note your game will still do this because it is nay impossible to test everything before the users get their dirty little hands on the game.

Tip.2 Wrap your Debug.anythings in if(Debug.isDebugBuild) that way you dont have to bother removing all of them when you release.

Tip.3 I generally dont worry about warnings (still a good idea to fix them) and I'm 90% sure they dont effect performance.

Tip.4 if you have Debug stuff in any Update() method just remove it from the build. Update() is called once per frame and you want to keep it as clean as possible. Then again with the power of today's devices a couple more if's wont do anything noticeable but is's just a good practice.

Null Reference Exception

A NullReferenceException is a runtime exception that happens when you haven't set a variable to an instance of an object, and then attempt to use that object. For example, the following could cause a NullReferenceException if TestObj isn't set

using UnityEngine;

public class NullTest : MonoBehaviour
{
    public GameObject TestObj;

    void Update()
    {
        // This throws an Exception
        TestObj.transform.position = new Vector3();

        // This line won't get called
        Debug.Log("Won't get here");
    }
}

While this doesn't come with a performance hit that I'm aware of, you are forcing Unity to catch the exception. In a normal application the NullReferenceException would stop the program and the user could not continue, but Unity catches that exception and carries on, which can lead to odd game behaviour.

A good approach is to use defensive programming to ensure that you get as few errors as humanly possible. It's worth pointing out that it's easy to go overboard with null checks (one early mistake a lot of people make is to put them everywhere), so keep the check to things you can't control yourself (i.e. public MonoBehaviour properties, GetComponent calls etc).

In our (very simple) example above, a defensive approach could be:

using UnityEngine;

public class NullTest : MonoBehaviour
{
    public GameObject TestObj;

    void Update()
    {
        // Avoid an exception by testing that TestObj is not null
        if (TestObj != null) {
            TestObj.transform.position = new Vector3();
        }

        // This line will now get called
        Debug.Log("Gets here");
    }
}

Or, if TestObj was integral to the Update (e.g. it's used quite a bit throughout the method), you could simply exit the Update. Note the #if UNITY_EDITOR here, which is a preprocessor directive so that the Debug.LogError doesn't get built into your live build

using UnityEngine;

public class NullTest : MonoBehaviour
{
    public GameObject TestObj;

    void Update()
    {
        // Avoid an exception by exiting from Update if TestObj is null
        if (TestObj == null) {
            // Optionally log your error
            #if UNITY_EDITOR
                 Debug.LogError("TestObj is not set");
            #endif

            // Exit the update
            return;
        }

        TestObj.transform.position = new Vector3();

        // This line will now get called
        Debug.Log("Gets here");
    }
}

Debug.Log

Debug.Log, on the other hand, is incredibly resource heavy, especially when called in an Update. Really your build shouldn't contain any Debug messages so you should aim to remove them where possible. As @uri-popov says in their answer, you can use Debug.isDebugBuild to stop these messages appearing on release.

However, a better approach may be to use preprocessor directives to stop your Debugs from ever even being compiled into your release. This works by telling the compiler to skip over the lines of code that aren't applicable, so that your release build never has to do a check to see if it's in debug mode as it's done at compile time.

These kinds of errors are exceptions which abort your functions in unintended ways.

As such they can speed up or slow down the execution of your game (by skipping vital pieces of code), but the question about speed it the wrong question in this situation.

Fix the code.