[Design Choice Discussion] Instancers and Garbage Collection
See original GitHub issuehttps://discord.com/channels/640589221136171020/643165315546742785/1000332183057203210
Scriptable Objects (even the in-scene in-memory runtime copies) are not free’d if there is no reference pointing to it like normal objects (no garbage collection).
Freeing them requires to call Resources.UnloadUnusedAssets
which is a kinda performance heavy call.
Also it is not really possible to Destroy the atom-instances in the instancers OnDisable since there could be remaining references (if destroy works at all for them).
When fiddling around with my own SOArchitecture approach my first implementation of Instancers wouldn’t create SOs, but simple classes. at runtime there is no real need for an SO. Not sure if this would be suitable for Atoms without an rework, though.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:6
Well, in such case I guess having an additional class wouldn’t hurt. Fortunately, I’ve implemented a unit testing infrastructure for UnityAtoms, so it will be easy to test it (I used the almighty powers of Reflection to make unit testing easy with unity atoms).
I personally would be totally fine with having the instancers just behave like the atom instance. Like you did. Especially if it’s the easier approach.
For Ions I went full interfaces. I have PureIons (which are just classes), IonComponents (which are MonoBehaviours) and IonSOs (ScriptableObject) which all implement the same interfaces.
a IonReference is basically just a fancy InterfaceHelper that allows putting anything that implements that interface.
Unity 2022+ definitely supports generics, to a pretty far extend just not for SerializedReferences and Assets.