Official Unite Now - Optimization Tips for Maximum Performance – Part 1

Thanks Arturo for the presentation and thanks Carol for this forum post. I'd have missed the session if you didn't post it here.

I would like to know why is Unity Technologies repeating themselves, rather than fixing the issues you want us to workaround?

There are a few slides in the presentation where I believe Unity could just fix/solve it on the engine side, rather than relying on every customer to work around it.

I just pick one example to get the idea across, you can apply this to more things presented in this, and other Unite sessions.



You talk about "GameObjectB" getting transformed, even though it wouldn't need and the recommendation is to restructure the hierarchy.

A specific hierarchy often makes sense, e.g. to communicate relationship.

The solution to this specific problem shouldn't be the recommendation that customers have to rethink/reorganize their hierarchies. The solution should be to find a way to allow us to use such hierarchies, without sacrificing performance.

I've picked this very example, because you've talked about it in Unite sessions, you blogged about it and you wrote tutorials about it. Use that energy to fix the problem instead.

Have a great day!

 

Specially when certain Unity features rely on having an hierarchy, like LODGroups. I don't get this resistance in fixing/improving core features like Transform hierarchy inneficiencies and the Resources system, pushing the onus on developers by introducing completely different systems which are more complex and more difficult to use.

 

I believe @willgoldstone has mentioned that hierarchy folders are being worked on.

 

I think we’re getting a bit sidetracked with the specific example Peter chose.

I have watched / read / attended various events and docs and articles about optimization, and most of them contain tips along the lines of:

“you know about Unity feature X? If you care about performance, don’t use it, it’s the worst thing ever, instead here is how you can work around it and make your game run 20x times faster”

Which comes back to what Peter was trying to say (I think): instead of wasting energy telling users about workarounds (and then your users wasting energy implementing those), why don’t you just... fix your features?

 

Agreed, and to point out that it is indeed possible to fix, here is an asset that did just that

https://assetstore.unity.com/packages/tools/utilities/hierarchy-folders-157716

 

Yep, that's what I tried to express.

It's the overall way how Unity Technologies handles inefficiencies and not really related to a specific feature.

They should consider to change their mindset from "Every customer should workaround xyz" to "We fix xyz, so everybody can use it without regret".

 

Would adding the

MethodImplOptions.AggressiveInlining

attribute have the same performance benefit when used for such a simple getter?

Code (CSharp):

1. public int Health
2. {
3.     [MethodImpl(MethodImplOptions.AggressiveInlining)]
4.     get { return health; }
5. }

 

Sometimes. Unfortunately the AggressiveInlining is just a hint for the JIT, not a command. So, as usual with C#, the answer is maybe, maybe not. And AFAIK with Mono it is even worse.

I don't like this example though, it is messy and not really necessary most of the time. It is a typical micro-optimization which is great only if you're developing your hot-path but doesn't give you real benefit otherwise (minuscule, comparing how messy it is) .

 

@AskCarol, you should update the URL to https://resources.unity.com/unitenow/onlinesessions/optimization-tips-for-maximum-performance-part-1, the one you have posted just goes to the landing page for Unite Now.

That example from the slides is broken, since the health field went from private to public.

Assuming the example is a MonoBehaviour, the amount of serialized data is different between the editor and builds, and deserialization will error out.

So the correct version of the code would have the #else version be:
[NonSerialized] public int Health;

 

I'm also fishy about the "move rigidbodies in FixedUpdate" tip from a performance standpoint. Auto Sync Physics Transforms was introduced quite a few years ago, and defaults to off, so unless you turn it on or manually call it, moving a transform with a rigidbody will not cause a physics sync anymore.

 

It might not sound much, but in my experience if you have 20+ of the same thing running a complex Update function little things like using fields instead of properties, and reducing indirections (aka: use locals and fields to reduce the number os dots in your functions) do help in shaving off that last millisecond or two that's keeping you from hitting your frame time targets.

Doing it everywhere, however, is just making your code harder to read. Always base optimization decisions on profiling data.

 

Firstly why are these videos unlisted on Youtube? After watching the first I went to the Unity channel and tried to find the second and couldn't.



Regarding using hash values it should be noted that they do not guarantee against hash collisions and that while the chance of this happening in a real project is virtual zero, it does remain a possibility.

As such I feel this should have been mentioned and should be in the docs too. Its important as it not only affects the developer if they get a stringToHash it also affects the underlying feature too - for example the Animator, even if you use unique names are converted to hashes internally so if they cause a clash then they clash and there is nothing you can do about it.

The problem isn't that the hashing system is bad, or even that hashing itself is bad, its the lack of feedback and information that there may be a collision. Thus someone, somewhere, some time could run into this and find the wrong animation or trigger playing in an animator and waste days trying to fix an almost invisible issue. In fact I wouldn't be surprised if someone has already ran into this and accidentally fixed it by simply renaming an animation or trigger and never getting to the bottom of why it caused a problem.

link to discussion

 

There's been arguments about the hash issue before. I can't quite remember what we found out, but I think it's something like it's more likely that your entire development studio gets taken out by lightning than you getting a hash collision in an animator, so I'm not sure how relevant it is to write about it.

 

Doesn't the animator uses the standard C# string.GetHash() function? Because if you get a hash collision there, you would also get a hash collision on dictionaries using strings as keys too, and people use those a lot.

I did face a real case of hash collision once, but the algorithm was md5.

 

I think Dictionary solves hash collisions, so getting collisions there doesn't break stuff, it just slows you down. No clue what algorithm is used by the animator, though.

 

Would have been nice if @Aras left a note in his hashing post what hash algorithm Shader/Animator.StringToHash use
https://aras-p.info/blog/2016/08/02/Hash-Functions-all-the-way-down/

 

I wouldn't call hash collisions in this case a downside, just something to be aware about as it might explain weird behavior when everything else in ones code looks correct.

BTW although we've picked apart some of the tips in the video, I really like this approach of collecting them altogether in video. It could maybe have been a little bit tighter in editing, but the concepts and tips it covers is going to be useful information for developers.

Which is totally the wrong attitude to have to a problem like this and one that eventually can and will lead to a bug for someone, somewhere. Obfuscating the issue exists just because its so unlikely to happen is terrible practice, when a simple one or two lines added to the documents could save a developer a huge amount of time and effort trying to track down an issue.

I might even go further and like to see Unity add some form of hash checking at build time. I was thinking that it might be difficult, but since ( in case of Animator ) all triggers and animation states need to be defined during development and since all of those strings are internally converted to hashes anyway, I feel it should be easily enough to check for collisions and throw up a warning at some point.

ooh I missed this one. I'm so bad at checking blogs these days, which is a shame as Aras's were always informative and good fun. Interesting his tests of CRC32 on 235886 words shows 5 collisions. Its still very low, that any one developer is unlikely to find a collision in their project, but I wonder across the millions of developer projects whether that chance increases.

Though as I said, I have no problem with the hash used, I'm just wary that there was never really any discussion about potential collisions, and Unity doesn't even both to take steps to inform/warn the user in cases where it should be able to detect them.

 

+1

 

Hi, don't you store any serialisation version number along your data?

 

So if a collisions can be predicted, could you folks add an error message at compile time when it's detected that two != strings produce a == hash?

 

In the video you say "reduce hierarchy complexity" and in the "Project Organization" article you say "Use hierarchy to group objects".

Which of the two methods should I follow?

 

I'm using this one:

https://assetstore.unity.com/packages/tools/utilities/hierarchy-folders-157716

 

I don't organize my scene with empty GO, everyone's gotta carry their weight at the mine!

 

A more advanced optimization video such as one on burst or jobs would be cool!