Optimizing Unity Editor and Rider: Essential Performance Settings

Introduction

In medium and large Unity projects, the Unity Editor can be slow, and you may waste a lot of time waiting. Over my career, I have collected some tips to improve the speed of both Unity Editor and the Rider IDE. This article only covers settings to make the Unity Editor and Rider run faster and does not include any code changes for your project. This means you can use these tips in any project. I use and recommend all of these settings, but keep in mind that each one has a trade-off. Choose the ones that best suit your project's needs.

1. Disable Asset Auto-Refresh

In Unity, go to Preferences → Asset Pipeline and set Auto Refresh to Disabled.

In Rider, go to Settings → Unity Engine and uncheck Automatically refresh assets in Unity.

Turning off auto-refresh saves you time by avoiding extra asset imports, compilations, and other background tasks. Just remember: with auto-refresh off, your assets will only update manually via [Ctrl + R] or through Assets → Refresh.

With this setting you should stay with such sequence: code in Rider, switch to Unity when ready, manually refresh assets using [Ctrl + R] (or Assets → Refresh), wait for recompilation or reimport, and then press play to test your changes. It might take a little time to adapt this method, but in my experience it is worth it.

2. Configure Script Changes Behavior

This tip is useful for those who do not want to disable Auto-Refresh. The idea is to stop script compilation during play mode. In Unity, go to Preferences → General and set Scripts Changes While Playing to Recompile After Finishing Playing.

If you forget to exit play mode before changing your scripts without this change, Unity can behave unexpectedly and show many errors. Use this setting with care if you are using any Hot Reload solutions.

3. Disable Domain Reload

Within the Unity Editor, navigate to Project Settings → Editor and, under the When Entering Play Mode section, select Reload Scene Only.

This setting can significantly speed up the process of entering play mode, especially in projects with a large codebase. However, it's important to be aware of its side effect: since the domain is not reloaded, any static fields will retain their values between sessions. For example, if a static field is set to 42 during runtime, it will remain 42 at the start of the next play mode session. To address this, consider limiting the use of static fields or ensure they are explicitly reinitialized when your application starts.

4. Debug Code Optimization

In Unity, navigate to Preferences → General and ensure that Code Optimization On Startup is set to Debug. This is the default setting in Unity, so no changes are necessary.

I mention this because some suggest switching this setting to Release for performance measurements or to more closely mimic the final build code. I strongly advise against this approach. The code executed on your target device will differ regardless, as Unity uses IL2CPP for further compilation—even if your target is a PC with the Mono backend, the build process involves more than just compilation. Essentially, all performance measurements should be performed on the actual device, making it unnecessary and counterproductive to sacrifice editor compilation time. I recommend keeping this setting at Debug.

5. Disable Texture Compression on Import

In Unity, navigate to Preferences → Asset Pipeline and set Compress Texture On Import to Disabled.

This setting stops textures from being compressed when they are imported. Instead, texture compression will happen during the build process. This is very useful for large projects with many graphical assets, especially if you do not work directly with graphics. Without this setting, every time you add new assets (for example, when merging a new branch), you will wait for texture compression. By disabling it, you save time. The trade-off is that the game in the editor will use more memory and show uncompressed sprites, though the final build will have compressed textures.

6. MSBuild Version

In Rider, go to Settings → Toolset and Build → MSBuild Version and select the latest .NET MSBuild. If you are using the default Mono MSBuild (common on macOS), change it to .NET MSBuild. (If .NET MSBuild is not available, you can install it through Rider)

These settings do not change how your Unity game is built, but they affect how Rider compiles your code for IntelliSense and class usage hints. Older MSBuild versions—especially Mono—are much slower. For medium or large projects, using the latest .NET MSBuild can make Rider work much faster. The only small drawback is that if you use an IL Viewer, the IL code might look a bit different in Rider. In my experience, this is very rare. I strongly recommend using the latest .NET MSBuild.

7. Increase Rider Heap Size

In Rider, go to Help → Change Memory Settings → Maximum Heap Size and set it as high as your system's RAM allows. Increase this value wisely, keeping in mind that the Unity Editor also uses a lot of memory. To see how much memory you have available, open Task Manager on Windows (or Activity Monitor on macOS) while both Unity and Rider are running.

8. Disable Solution-Wide Analysis in Rider

In Rider, go to Settings → Inspection Settings and disable Enable solution-wide analysis.

Turning off this analysis can make Rider run faster, use less memory, and start up quicker. In my experience, solution-wide analysis does not help much with Unity projects, so it is safe to turn it off. If you need it for deep analysis sometimes, you can turn it on only when needed.

9. Disable Unnecessary Plugins in Rider

In Rider, go to Settings → Plugins and disable all plugins you do not use. By default, plugins for other languages and web development are enabled. This will greatly enhance your user experience and reduce Rider's startup time.

10. Utilize 'Hot Reload' Solutions

Hot reload solutions for Unity dynamically update the IL code of modified scripts without restarting the application. They monitor file changes, trigger incremental recompilation of the altered assemblies, and inject the new code into the running process while preserving the current state.

In some cases, Hot Reload solutions can save you from recompilation. Two popular options are:

- Fast Script Reload (free): [Link]

- Hot Reload (paid): [Link]

Hot reload (fast script reload) works best when you make many small changes in Play Mode, such as adjusting code-driven animations or rapid prototyping. However, it has limits. Sometimes, automatic code change detection fails, and you must recompile manually with Ctrl+R. It also does not support all types of changes (for example, changes in async methods). This may require you to exit Play Mode or restart Unity for stability.

I recommend using Hot Reload solutions when you need to work a lot in Play Mode or during fast prototyping. For regular development, they might cause problems because you are not always sure if your code is fully updated or if a full recompilation is needed.

Conclusion

These tips can save you time and improve your workflow. Remember that each change has its trade-offs, so choose what works best for your. Try these settings and see how much faster your Unity Editor and Rider become. Happy coding!