Will putting Screen.orientation in Update affect the performance?

Question

If I put Screen.orientation in Update to detect whether the device is in landscape orientation, will it affect the game's performance?

if(Screen.orientation == ScreenOrientation.LandscapeLeft || 
Screen.orientation == ScreenOrientation.LandscapeRight)
{
}

Answer 1

As Philipp says in a comment above, the best answer to every question of the form "how does X affect performance?" is:

Profile your game and find out.

Unity has some great profiling tools you can use to inspect the performance of your game in detail. You could set up artificial tests, accessing Screen.orientation from dozens or hundreds of script instances, just to exaggerate the impact in the profiler to see if you get a noticeable blip. Or you can just test your planned use inside your actual game scene, to test whether it makes any difference there. Even an expensive function can be fine if you only call it a bit, or if your game's stuck waiting for something else (like rendering or an asynchronous load) anyway.

---

Since I don't have access to your game to profile it - that's your job - the best reassurance I can give you is to peek at the code. We can find (most of) the implementation of Screen.orientation in Unity's publicly-released C# source code reference.

Specifically, in the Screen class:

public static ScreenOrientation orientation
{
    get => ShimManager.screenShim.orientation;
    set => ShimManager.screenShim.orientation = value;
}

That calls into the ShimManager class:

private static List<ScreenShimBase> s_ActiveScreenShim = new List<ScreenShimBase>(
                                                          new [] { new ScreenShimBase() } 
                                                         );
internal static ScreenShimBase screenShim => s_ActiveScreenShim.Last();

And this ScreenShimBase has different implementations for different cases (editor views, device simulator, and presumably, actual device screens). We don't have access to the code used in built executables, but we can peek at how it's simulated in ScreenSimulation:

public override ScreenOrientation orientation
{
    get => m_RenderedOrientation;
    set
    {
        if (value == ScreenOrientation.AutoRotation)
        {
            m_AutoRotation = true;
            ApplyAutoRotation();
        }
        else if (m_SupportedOrientations.ContainsKey(value))
        {
            m_AutoRotation = false;
            RequestOrientation(value);
        }
    }
}

So, there's some overhead in calling a pair of static getters (the runtime inserts a check that the static members have been initialized) and in pointer-chasing (follow a pointer to the Screen class then follow a pointer to the ShimManager class then follow a pointer list of shims, then jump to the last item in that list, then follow a pointer to the active shim). But after that, it's just returning the value of a cached variable.

While the static access and pointer-chasing aren't free, they're not anything worse than you get when you write:

int itemCount = GameManager.ActivePlayers[i].Inventory.carriedItemCount;

So if you're not being picky about that kind of code, you probably shouldn't worry about Screen.orientation either - at least not until you see it showing up on your profiler.

It's possible that Unity compiles the built version of your game against a platform-specific version of the Screen class that bypasses these shims entirely and just returns a cached value for the screen orientation directly, making it even cheaper than the code above would suggest. I'd find it very surprising if this getter did any expensive computation like an OS call or hooking into a hardware driver every time you read this value.

But of course, the only way to be sure is not to take the word of some Internet rando like me, but to profile your game.