Return to Answer

In general, frequently instantiating and destroying game objects should be avoided. Expensive build-up and tear-down operations happen behind the scenes whenever you do that. Unity will also constantly allocate and deallocate memory. This fragements the RAM used by your game which in turn harms locality of reference which harms execution performance.

However, in your particular situation, this is unlikely to matter. It matters, for example, in a bullet hell shooter where you would have to create and destroy several bullets each frame. In that case you would reuse objects in an object pool.

  The downside of object pooling, besides the added complexity, is that it prevents your game from returning memory it doesn't need anymore.

But in your case you are only going to create and destroy an object every few minutes on average. When something happens so rarely, it is not performance critical. The memory aspect does not apply either, because at one point the player will have collected all items anyway. So the best practice will be to do whatever leads to sourcecode which is easier to understand, debug and maintain.

In general, frequently instantiating and destroying game objects should be avoided. Expensive build-up and tear-down operations happen behind the scenes whenever you do that. Unity will also constantly allocate and deallocate memory. This fragements the RAM used by your game which in turn harms locality of reference which harms execution performance.

However, in your particular situation, this is unlikely to matter. 

It matters, for example, in a bullet hell shooter where you would have to create and destroy several bullets each frame. In that case you would reuse objects in an object pool. The downside of object pooling, besides the added complexity, is that it prevents your game from returning memory it doesn't need anymore.

But in your case you are only going to create and destroy an object every few minutes on average. When something happens so rarely, it is not performance critical. The memory aspect does not apply either, because at one point the player will have collected all items anyway. So the best practice will be to do whatever leads to sourcecode which is easier to understand, debug and maintain.

In general, frequently instantiating and destroying game objects should be avoided. Expensive build-up and tear-down operations happen behind the scenes whenever you do that. Unity will also constantly allocate and deallocation of memory. This fragements the memory used by your game which in turn harms locality of reference which harms execution performance.

However, in your particular situation, this is unlikely to matter. It matters, for example, in a bullet hell shooter where you would have to create and destroy several bullets each frame. In that case you would reuse objects in an object pool.

The downside of object pooling is that it prevents your game from returning memory it doesn't need anymore.

But in your case you are only going to create and destroy an object every few minutes on average. When something happens so rarely, it is not performance critical. The memory aspect does not apply either, because at one point the player will have collected all items anyway. So the best practice will be to do whatever leads to sourcecode which is easier to understand, debug and maintain.

In general, frequently instantiating and destroying game objects should be avoided. Expensive build-up and tear-down operations happen behind the scenes whenever you do that. Unity will also constantly allocate and deallocate memory. This fragements the RAM used by your game which in turn harms locality of reference which harms execution performance.

However, in your particular situation, this is unlikely to matter. It matters, for example, in a bullet hell shooter where you would have to create and destroy several bullets each frame. In that case you would reuse objects in an object pool.

The downside of object pooling, besides the added complexity, is that it prevents your game from returning memory it doesn't need anymore.

But in your case you are only going to create and destroy an object every few minutes on average. When something happens so rarely, it is not performance critical. The memory aspect does not apply either, because at one point the player will have collected all items anyway. So the best practice will be to do whatever leads to sourcecode which is easier to understand, debug and maintain.

In general, frequently instantiating and creating game objects should be avoided. Expensive build-up and tear-down operations which happen behind the scenese whenever you Instantiate or Destroy a game object. Unity will also constantly allocate and deallocation of memory. This fragements the memory used by your game which in turn harms locality of reference which harms execution performance.

However, in your particular situation, this is unlikely to matter. It matters, for example, in a bullet hell shooter where you would have to create and destroy several bullets each frame. In that case you would reuse objects in an object pool.

But in your case you are only going to create and destroy an object every few minutes on verage. When something happens so rarely, it is not performance critical. So the best practice will be to do whatever leads to sourcecode which is easier to understand, debug and maintain.

In general, frequently instantiating and destroying game objects should be avoided. Expensive build-up and tear-down operations happen behind the scenes whenever you do that. Unity will also constantly allocate and deallocation of memory. This fragements the memory used by your game which in turn harms locality of reference which harms execution performance.

However, in your particular situation, this is unlikely to matter. It matters, for example, in a bullet hell shooter where you would have to create and destroy several bullets each frame. In that case you would reuse objects in an object pool.

The downside of object pooling is that it prevents your game from returning memory it doesn't need anymore.

But in your case you are only going to create and destroy an object every few minutes on average. When something happens so rarely, it is not performance critical. The memory aspect does not apply either, because at one point the player will have collected all items anyway. So the best practice will be to do whatever leads to sourcecode which is easier to understand, debug and maintain.