Performance optimizations in the C# source code

Unity Engine
, , , , ,
1

I was going through the C# source code, and found a lot of places to optimize performance. The repo doesn’t accept PRs according to the readme, so I wanted to post here.
They’re small, but all can be semi-automatically fixed using Roselynator in Visual Studio.
While these are often micro optimizations, since Unity is used (and abused) in the millions, this might be worth picking up. I do believe some of these can improve Unity’s (editor) performance for all users, especially with some changes reducing garbage allocation. I expect that your own Project Auditor tool can also find a lot more. If you are interested in this, I can dig into that and filter out the easy performance wins.

Finds:

Or just use length instead of LINQ Count

image
image1990×501 94 KB

2

These I would expect the compiler to be clever enough to figure out all by itself. They seem like obvious and trivial auto-optimizations.

I’m certain that str == "" vs str.Length == 0 makes absolutely no difference.

With a bit of knowledge of the foundational collection I’d expect even the single-item Add vs AddRange, and Count() vs Any() to get optimized away but if not, those might be worthwhile improvements.

3

I am not sure if engine code, especially that which runs in Editor mode, gets optimized properly.
I have done performance tests for multiple of these, and in editor, mono runtime, and IL2CPP there are measurable differences.
The empty string comparison was one of the bigger differences, with == “” allocating garbage and length == 0 having no garbage and better performance.

These tests were in Unity 2021 or 2022, so maybe it has improved. So far I have learned not to trust auto optimizations as they don’t always happen.

4

For runtime, I would as well.

But in the editor, I would imagine code is compiled for debugging which would disable many optimizations - certainly any that would modify instructions that would inhibit being able to step through with a debugger, no?

5

Here some info on the string checks btw

6

So I only checked the very first screenshot you provided ShouldShowRequestPermissionRationale in source…
And it looks like we strip out some information from the reference?

        public static bool ShouldShowRequestPermissionRationale(string permission)
        {
            if (string.IsNullOrWhiteSpace(permission))
                return false;
#if UNITY_ANDROID
            return I-will-keep-this-stripped-just-in-case-that-is-done-for-a-reason-and-might-get-me-into-trouble
#else
            return true;
#endif
        }

So due to that #if UNITY_ANDROID that optimization becomes impossible, no?
Maybe it’s just this one place, maybe you should take all of these optimizations with a grain of sailt ; )

7

I might have checked out a different branch than you. For me this did not know. Otherwise VS doesn’t flag it as well.
Technically you can make a seperate return for both Android and other platforms, but that’s less readable (and likely not worth it in that case).

Would love to hear your thoughts on some other issues

8

I think he means the repo on GitHub is not the real and complete source, it’s just for reference. Some code might be stripped out before it is pushed to GitHub. On the other hand, he double checked the first image on the real source.

9

Yes, @Laicasaane is correct - what you see on Github is not identical to the source we are actually authoring internally, particularly when it comes to platform-specific codepaths. It’s not common - most of our platform-specific code is isolated into directories that are wholly omitted from the source we publish - but it does happen in a few places.

It’d be interesting to run the Roslynator analysers across the codebase internally. Adding it to my list of things to investigate…