How Odin affects your project

While the scope of Odin is far-reaching, Odin in fact is very low-impact. We have gone to great pains to ensure that Odin is stable and reliable, and that it has a minimal impact on your project. Practically everything Odin does can be toggled on or off in the preferences, which can be found under Tools -> Odin Inspector -> Preferences.

Inspector upgrades

Odin's primary function is, of course, to upgrade the inspector for all of your types. In older versions of Odin ( and down), Odin generated a special .dll full of custom editor types in order to facilitate this. This would often cause a tedious extra recompilation after scripts had been changed. In versions 1.0.5 and up, this is no longer the case, and Odin no longer causes any extra recompilations.

In all versions of Odin, the inspector upgrades can be fully enabled or disabled in the Editor Types preference window, either globally in the entire project by toggling the "Enable Odin In Inspector" value, or for special types individually by toggling Odin on or off in the "Draw Odin for" sections of the window. Therefore, Odin never applies unless you want it to - and it is always quick to get Odin out of the way, should you feel the need.

Serialization performance

Odin's serialization system is highly optimized, but it is by virtue of its nature and feature set not quite as fast as Unity's own. It is very fast, but if you use it heavily to save and load massive amounts of data regularly, you will see a performance hit. It is always best to use the serialization system prudently. For more details, please see our words of caution here.

Scans of all loaded assemblies and types

Odin performs scans of all loaded assemblies and types each time the project is loaded, which generally adds a few fractions of a second to your script reload time in the editor, and a delay of a few milliseconds the first time the serialization system is invoked in both builds and in the editor.

Dynamic assemblies in the current AppDomain

In the editor, and in builds on non-AOT platforms (as a rule, non-IL2CPP Standalone and Android), Odin maintains at least one dynamic assembly in the current AppDomain to support fast serialization through on-demand emitted type formatters - so if you have code which scans all loaded assemblies, remember that some of them may be marked dynamic.