How costly are those Instantiate and Destroy calls on Scriptable Object? Problem with status effect (buff/debuff) system made by scriptable objects

Questions & Answers
1

I made a status effect system using scriptable objects, it has some main values like totalDuration, remainingDuration, … and a Coroutine to automatically make itself expired after remainingDuration runs out. I also have a effectHandler class that stores a list of statusEffectSO and automatically removes them when they’re expired (also for displaying UI).

So I put everything in place for testing and I realized they were referencing the same asset SO file. That means when ONE of the effect runs out, ALL other effects on different targets also run out.

Then I applied a band-aid solution so that every time I apply a new effect to the effectHandler class, the handler will INSTANTIATE that effect to make an instance of the effect values so that it will run independently. Then when it is expired I will DESTROY it and remove from the list.

TLDR: To make my statusEffectSO system works, I Instantiate a copy of the effectSO then Destroy that copy when the effect expire.

**The question is: **
How costly are those Instantiate and Destroy calls on Scriptable Object? How fine is this? Or is there a better way to do this?

2

I don’t think there is anything wrong with how you are instantiating objects if you need them. It does cost but clearly if you need another object you need to instantiate it so that is an expected cost.

The bit you could save performance on is, instantiating and destroy multiples of the same object. If you want to make it cheaper and you are going to be instantiating and destroying those types of objects often you should look to use an ObjectPool.

Essentially a list of those objects that you don’t destroy, instead you activate them when needed and deactivate them when finished. So it saves on GC and the cost of instantiating.