As Philipp says in a remark above, the most effective reply to each query of the shape “how does X have an effect on efficiency?” is:

Profile your recreation and discover out.

Unity has some nice profiling instruments you should utilize to examine the efficiency of your recreation intimately. You might arrange synthetic exams, accessing Screen.orientation from dozens or tons of of script cases, simply to magnify the influence within the profiler to see should you get a noticeable blip. Or you possibly can simply check your deliberate use inside your precise recreation scene, to check whether or not it makes any distinction there. Even an costly perform might be advantageous should you solely name it a bit, or in case your recreation’s caught ready for one thing else (like rendering or an asynchronous load) anyway.

Since I haven’t got entry to your recreation to profile it – that is your job – the most effective reassurance I can provide you is to peek on the code. We can discover (most of) the implementation of Screen.orientation in Unity’s publicly-released C# supply code reference.

Specifically, within the Screen class:

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

That calls into the ShimManager class:

non-public static List<ScreenShimBase> s_ActiveScreenShim = new List<ScreenShimBase>(
                                                          new [] { new ScreenShimBase() } 
                                                         );
inside static ScreenShimBase screenShim => s_ActiveScreenShim.Last();

And this ScreenShimBase has completely different implementations for various instances (editor views, machine simulator, and presumably, precise machine screens). We haven’t got entry to the code utilized in constructed executables, however we are able to peek at the way it’s simulated in ScreenSimulation:

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

So, there’s some overhead in calling a pair of static getters (the runtime inserts a test that the static members have been initialized) and in pointer-chasing (comply with a pointer to the Screen class then comply with a pointer to the ShimManager class then comply with a pointer listing of shims, then bounce to the final merchandise in that listing, then comply with a pointer to the lively shim). But after that, it is simply returning the worth of a cached variable.

While the static entry and pointer-chasing aren’t free, they are not something worse than you get while you write:

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

So should you’re not being choosy about that sort of code, you most likely should not fear about Screen.orientation both – a minimum of not till you see it exhibiting up in your profiler.

It’s doable that Unity compiles the constructed model of your recreation towards a platform-specific model of the Screen class that bypasses these shims totally and simply returns a cached worth for the display orientation straight, making it even cheaper than the code above would counsel. I’d discover it very shocking if this getter did any costly computation like an OS name or hooking right into a {hardware} driver each time you learn this worth.

But in fact, the one method to make certain is to not take the phrase of some Internet rando like me, however to profile your recreation.