unity – Will placing Display.orientation in Replace have an effect on the efficiency?

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

Profile your sport and discover out.

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

Since I haven’t got entry to your sport to profile it – that is your job – the very best reassurance I may give you is to peek on the code. We will discover (most of) the implementation of Display.orientation in Unity’s publicly-released C# supply code reference.

Particularly, within the Display class:

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

That calls into the ShimManager class:

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

And this ScreenShimBase has completely different implementations for various circumstances (editor views, system simulator, and presumably, precise system screens). We do not have entry to the code utilized in constructed executables, however we will 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 verify that the static members have been initialized) and in pointer-chasing (comply with a pointer to the Display class then comply with a pointer to the ShimManager class then comply with a pointer record of shims, then leap to the final merchandise in that record, then comply with a pointer to the lively shim). However after that, it is simply returning the worth of a cached variable.

Whereas the static entry and pointer-chasing aren’t free, they don’t seem to be something worse than you get once you write:

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

So if you happen to’re not being choosy about that sort of code, you most likely should not fear about Display.orientation both – at the very least not till you see it exhibiting up in your profiler.

It is doable that Unity compiles the constructed model of your sport towards a platform-specific model of the Display class that bypasses these shims fully and simply returns a cached worth for the display screen orientation immediately, making it even cheaper than the code above would counsel. I might 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.

However after all, the one manner to make certain is to not take the phrase of some Web rando like me, however to profile your sport.