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)
  • 1
    \$\begingroup\$ I wouldn’t check for something like this every frame unless for some reason you want the screen orientation to rapidly change. Instead, consider using an event that broadcasts when the screen’s orientation changes, and have other things listen for that event. \$\endgroup\$ Oct 24, 2022 at 10:14
  • 2
    \$\begingroup\$ You can check the performance impact of things like that yourself by using the Unity Profiler. It's one of the tools everyone who calls themselves an intermediate-level Unity developer should be familiar with. But my educated guess would be that you won't see a performance impact when you got that code on one component of one object, but it could be possible if you have it on 10 components of 1000 objects. \$\endgroup\$
    – Philipp
    Oct 24, 2022 at 10:53

1 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;
        if (value == ScreenOrientation.AutoRotation)
            m_AutoRotation = true;
        else if (m_SupportedOrientations.ContainsKey(value))
            m_AutoRotation = false;

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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .