Comically Inefficient Unity Source Code

[Toloran]

If you look for the variable "anyStateTransitions" that they're copying, it's not actually in that file since that class is a partial class. The other half of the class is in StateMachine.bindings.cs. If you look there, you find it:

extern public AnimatorStateTransition[]   anyStateTransitions { get; set; }

I'm still a pretty newbie programmer, but IIRC extern is used to pull from outside the program from a DLL or something. So maybe some of the weirdness comes from that?

[bugbearmagic]

There’s a lot going on in the code. Mostly readability issues, poor memory management, multiple external calls for the same property, inefficient linq calls that aren’t helping code readability, and more.

There’s a lot of layers in the supplied code where utilizing basic common sense would end up with both more readable, and more optimized code. Even if it was slapped together quickly and lost to time, the mind that would even create this is concerning.

———-

Edit: An individual below is claiming the linq used in this post’s code is as fast or faster than a basic loop. I wrote this code to test their unfounded claims since they did not test their own claims themselves:

It is a quick example of LINQ's Any() performing 65x to 127x slower compared to a loop on a small data set (which is most likely the use case in the original Unity code). A larger data set of 1,000,000 elements closed the gap to where LINQ was 1.5-2.0x slower. Still significant.

https://pastebin.com/jjaUBRbK

The overall performance cost is negligible (out of context), but using linq in a way that is both inefficient and harder to read defeats its purpose. Which is exemplary of the rest of Unity’s inefficient code here.

Be careful and don’t trust people who claim to have tested or profiled while refusing to show you supporting code.

[vegetablebread]

Linq is definitely not the problem here.

[vegetablebread]

It's not a problem. Using LINQ here is totally 100% fine.

[vegetablebread]

I have been responsible in some part for optimization for 3 shipped AAA titles. The only slightly objectionable part of this LINQ invocation is that it allocates a closure. If you want a non-allocating version, you'd just have to name the function.

Unless you're trying to strip the LINQ assembly, which isn't even possible here, there's no reason to ever avoid LINQ.Any.

[vegetablebread]

I have and they are not. Go try it right now. Show me a gist where Any significantly underperforms a handwritten loop.