Just to give this old question a definite answer:
Yes, you should destroy dynamically-created Sprite instances when you're done with them.
How can we check this?
Add a script like this to your scene. This creates 50 new random sprites every frame.
public class SpriteTester : MonoBehaviour { public Texture2D tex; Sprite[] _sprites = new Sprite[50]; // Update is called once per frame void Update() { for (int i = 0; i < _sprites.Length; i++) { // DestroyImmediate(_sprites[i]); _sprites[i] = Sprite.Create( tex, new Rect(Random.Range(0, 50), Random.Range(0, 50), Random.Range(1, 50), Random.Range(1, 50)), new Vector2(Random.Range(0, 50), Random.Range(0, 50)) ); } } }
Open the Unity profiler by going to Window > Analysis > Profiler and run your scene. You'll see the "Total Used Memory" creeping up slowly from the memory we're allocating for all these sprites.
Now uncomment this line:
DestroyImmediate(_sprites[i]);
This releases the memory associated with the old sprite before we allocate a new one. Run your scene again, and you'll see "Total Memory Used" stops climbing.
There's still some garbage collector churn though (about 2 KB for 50 sprites, or ~40 bytes per sprite), so this isn't free - avoid creating and destroying sprites frequently if you can reasonably cache/reuse them instead. But if you only need to do this occasionally, like during a level transition or when loading a mod, user-generated content, or other asset you can't predict in advance, 40 bytes per sprite won't break the bank. Just remember to destroy it when you're done with it!
What I want to demonstrate with this answer is not just whether we should destroy sprites, but that whenever you have any question about what costs more time or memory, the best way to answer that question is to profile it. It's often very easy to do so - this example only took about a dozen lines of code and 5 minutes to test. Writing the text of the answer took more time and thought. 😉