Feel free to post your questions before, after and during the session. Unite Now Session
Unity evangelist Arturo Núñez knows games inside and out. In the first session of this two-part series, profit from Arturo’s experience helping game developers optimize performance. He’ll cover the underlying architecture of Unity’s core systems so you’ll know how to get the most out of Unity and your game.
A team of product experts from across Unity will be available during and after the session. Our Community team will continue to field questions to foster an ongoing discussion with the community. Please feel free to ask your questions in this thread.
Some basic rules
Only questions related to the topics of the session are permitted.
All questions will be fielded by our Community Managers (@LeonhardP and @AskCarol)
Replies will have to be approved by the moderators to show up in the thread.
Once approved, the questions will be forwarded to the relevant experts.
We really look forward to hearing from the community. Thank you!
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.
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 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?
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) .
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.
Hi Peter, thanks a lot for your comment and you are right, we need to fix many things and we are! However, some of these things are not trivial to fix. But, we do have people working on these small performance things that hopefully will make all these tips obsolete soon.
As for the hierarchy changes, I would also say that it depends on the project. In many cases it won’t make a difference but in some cases, is a nice thing to know that there is a potential performance benefit in changing the hierarchy.
I agree on that, we need to fix it on our end. But today, those problems still persist and we want to make sure that we are transparent and people know that those problems can be at least worked around.
Totally, many of these tips are usually micro optimizations that don’t make sense to implement. However, my intention was to show that in some cases that might be an issue and there’s space for optimizing.
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.
We are releasing them as part of a long term content event for Unite Now. The second video wasn’t yet available at the time of your posting. But you can now check it out here.
Thanks for the note Noisecrime. I really wasn’t paying too much attention to this issue (hash collision) but yes, we should be making a note about possible downsides of using X approach.
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.
