How to speed up the compilation.

I worked at a project with 1800 assemblies. Everything was slow: Unity compilation, domain reload, Rider processing all these solutions. So it's a good advice to keep track of your compilation and assemblies count in control

The next default tip: disable domain reload on entering play mode

Use ifs in shaders instead of keywords. Profile it. It might be better for your case.

The final tip on shaders about how to check what goes into build

Assets loading section

Disable audio preloading
Tune Async Upload Pipeline
Strip shader variants, less shaders to load and compile

It was quick overall. Not as rich in advice as previous years. Especially 2017-2019 talks on the same topic, which are my all time favourites.
Make sure to check them, here is my overview of these talks: https://gamedev.center/best-optimization-tips-by-unity-engineers-at-unite/

Talk: Keeping it simple and indie on Multiplayer

What a nice day-1 set of features for the speaker and his indie game

The Unity Engine Roadmap

It was impossible for me to share live at Unite all the great features they have planned as it was so packed. Check the recording and you'll definitely find something interesting for you.

I posted the most exciting stuff for me live on the 19th of November, what do you expect the most from the roadmap?

https://youtu.be/rEKmARCIkSI

#roadmap

Optimizing Burst matrix multiplications

A deep dive into optimizing matrix multiplications. A story of multiple optimization attempts, moving from basic implementation to hand-tuned intrinsics.
Key takeaways from the optimization journey:
* Switching to Unity’s Mathematics package (SIMD-friendly) immediately gave a massive boost over standard C#.
* The Low-Hanging Fruit: Using FloatMode.Fast allows the compiler to merge instructions into Fused Multiply-Add (FMLA).
* Reinterpreting NativeArray<Matrix4x4> as float4x4 helps the compiler see the data layout more clearly, reducing instruction count.
* Utilizing Affine Matrices (since most game objects don't use perspective projection) allows you to skip calculating the 0,0,0,1 row, saving significant cycles.
* Using Intrinsics and float4x3 to pack data tightly into vector registers.
This is a must-read if you are working on high-performance physics, skinning, or animation systems in Unity.

https://medium.com/toca-boca-tech-blog/optimizing-burst-matrix-multiplications-bfb301de80ce

#burst #optimiziation

Using DOTS to optimize GameObject gameplay: A case study from Survival Kids | Unite 2025

The recording is available now.

https://www.youtube.com/watch?v=ZkvK0mX-id4

#optimization

Unity 6.3 LTS is available

Hopefully, they are addressing old issues as well.

Key changes for me in 6.3:
* Platform Toolkit: A unified API for handling accounts, save data, and achievements across platforms (Steam, Consoles, Mobile).
* HTTP/2 Support: Now the default for UnityWebRequest where supported, reducing server load and device CPU usage.
* AssetBundles & Addressables: Improved with TypeTree deduplication, which can significantly reduce runtime memory usage and speed up build times.
* Sprite Atlas Analyzer: A new tool to identify inefficiencies, wasted space, and compression issues in atlases.
* SRP Batcher Improvements: A new API for dynamic custom values (Shader User Values) allows the SRP Batcher to handle per-instance data, a performant alternative to Material Property Blocks.

Has anyone tried this in production yet?

Also, for those who already upgraded from 2022 LTS: is it safer to step to 6.0 LTS first, or jump straight to 6.3 LTS?

https://unity.com/blog/unity-6-3-lts-is-now-available

#lts

Understanding Unity memory | Unite 2025

One of my favorite talks this year, which I recommended in my live report from Unite, is now available on YouTube.

https://www.youtube.com/watch?v=0y3erF2tzbI

#memory #unsafe

Why await Resumes on the Main Thread in Unity - SynchronizationContext

I have been working on projects that extensively use async, both Task and UniTask, for many many years already. And we always had a lot of strong engineers who understood the ins and outs of how it works in Unity. So I had a great opportunity to learn from them not only how it works, but, more importantly, how to use it correctly to avoid critical issues.

I have also conducted many dozens of interviews, and I noticed that a lot of people just use async and do not know the internals or about the existence of a custom synchronization context in Unity. And that is usually okay for 99% of cases, you are here to make games in the end. However, when this remaining 1% happens in a critical module, it may cause unpredictable harm, like players losing progress or an ANR rate three times higher than usual.

I also see a lot of confusion around asyncs in general. For example, some people assume that using await in Unity means creating new threads and doing multithreading, without realizing that it would be very inefficient to use multithreading for something like UniTask.Delay. It’s also easy to overlook the difference between creating threads and using the thread pool, or that an async method can execute synchronously. Sometimes people don’t fully grasp the purpose of ValueTask or what happens if the same UniTask is awaited twice. And I am not even talking about the magic that compiler does for us when we write "await" and the difference in how the async state machine is compiled in debug and release builds.

I also noticed that people who are willing to dive into how things work under the hood, and who show engineering curiosity, can troubleshoot issues much better. They don’t stop after the first unsuccessful step when we have tricky bugs to uncover.

So you don’t need to know what this post talks about to make games, but it will help you in the future not only pass heavy theory interviews (which is a widespread thing), but also prevent critical issues, which is extremely important when you work on a live game with millions of users.

https://discussions.unity.com/t/why-await-resumes-on-the-main-thread-in-unity-synchronizationcontext/1700147

#async #synchronizationcontext

Unity's Mono problem: Why your C# code runs slower than it should

* Unity uses Mono, a legacy JIT runtime → 2–3× slower than modern .NET
* Benchmarks: map generation and game startup take 100s in Unity/Mono, 38s in .NET (Debug mode)
* Even in Release mode: Mono 30s vs .NET 12s
* Mono JIT produces unoptimized machine code, lacks modern runtime features
* CoreCLR promises major speedups + modern APIs, SIMD, hardware intrinsics
* Burst compiler helps, but limited; CoreCLR would unlock broader improvements

To add to the author’s ideas, Editor performance is also a huge benefit, not just runtime. Slow iteration can cost hours per week, making iteration speed crucial for big teams and projects.

Working with LLMs adds another challenge: AI can sometimes break working code while fixing old bugs. Using unit tests to verify existing logic helps, but running them in Unity Test Runner is slow and requires a lot of manual work.

With a great idea from a friend, I created an infrastructure to run unit tests on the latest .NET without using the Unity Editor. This lets AI run the tests by itself to verify its changes, so no manual action is needed, and it takes mere seconds compared to Unity Test Runner.

I haven’t seen any info about this setup online yet, so either me or my friend might prepare a sample and a post describing how to set it up, but that’s still undecided. Drop a 💯 if you are interested

https://marekfiser.com/blog/mono-vs-dot-net-in-unity

#coreclr #performance