Question Do I need to destroy Instantiated ScriptableObjects not used anymore?

Hello, I am currently creating a tool for Unity and I am using ScriptableObjects to save some data. In order to preserve the original data, I Instantiate a new ScriptableObject from this to have a copy that I can modify then save if needed.

Code (CSharp):

1. Settings originalSettings;
2. Settings currentSettings;
3.  
4. currentSettings = Object.Instantiate(originalSettings);
5.  

But, when it comes to clear the currentSettings, I am doing this:

Code (CSharp):

1. currentSettings = null;

Should I destroy it before to free memory space or Unity do it itself?

Code (CSharp):

1. DestroyImmediate(currentSettings):
2. currentSettings = nul;

 

Yes, you should destroy objects you instantiate. Those objecty would be destroyed in rare cases when no references to it are hold anymore. However that only happens when you load a new scene or when Resources.UnloadUnusedAssets is called. Any object derived from UnityEngine.Object that you create / clone has to be destroyed by you. This include Texture2Ds, Meshes, Materials, GameObjects and other objects. Note that destroying a gameobject / gameobject tree will destroy all components attached to those gameobjects automatically.

Any UnityEngine.Object derived object is actually "tracked" on the native C++ side. You can actually find those again with FindObjectsOfType even when all references have been wiped.

ps: Note that you should be careful with DestroyImmediate. It's mainly used by editor code. At runtime you should use Destroy in 99% of all cases.

 

Thank you for this answer, I will do it right now !

 

Just a word to the wise, destroying Scriptable Objects can cause problemsTimeStamp 18:05)

I would just re-write that scriptable objects data, unless that can't be done, then I'd just use a static class.

 

It's only a problem if you don't null out any references to the SO.

Ideally instanced SO's would only be used in a small scope so there aren't dozens of references to them.

That said, instancing SO's always feels heavy handed to me, and in most cases would be better served by plain C# classes, with a potentially a scriptable object that can act as a factory for these plain objects.