.NET Tools Blog

Last time, we looked at Rider’s new performance indicators for Unity, which highlight expensive operations inside performance critical contexts, such as calling GetComponent inside an Update method.

These highlights are intentionally different to traditional warnings and suggestions because there is no easy “fix”, partly because the code isn’t necessarily wrong, but also because removing an expensive operation requires either changing the semantics of your code, or rearchitecting parts of your application (e.g. avoiding the use of SendMessage completely). These indicators provide context and awareness, and it’s up to you (and your profiler) to decide how, when and even if you want to address the advice.

Of course, there are always code patterns that can be easily and safely rewritten to perform better simply by using a different API or overload, or by caching values. In this post, we’ll take a look at some of these inspections and the Quick Fixes you can use to follow Unity’s own best practices and avoid some common performance issues in Unity.

Continue reading →

At JetBrains, we’re big fans of static analysis. Rider has over 1,200 inspections designed to warn about potential issues, or suggest changes, nearly all with quick-fixes to address the problem. Some are about consistency, such as naming standards and code style. Others warn about redundant, unused, or unnecessary code, or help you write terser, more modern code, making use of new language features. And of course, Rider will warn you about code quality issues, such as potential null-reference exceptions or other runtime issues like infinite loops.

Rider even has some Unity specific inspections and quick-fixes – such as warning about ambiguous usage of the ?? and ?. operators on Unity objects, incorrect method signatures for Unity’s magic methods, and so on.

But wouldn’t it be nice if Rider could help with the one thing that all Unity developers care about – performance? Surprise! Of course it can!

Continue reading →