# Pooling

In games where objects are frequently spawned and destroyed (projectiles, enemies, pickups, etc.), constantly creating and destroying GameObjects is expensive. Each instantiation allocates memory, and each destruction triggers garbage collection, which can cause frame hitches. This gets even worse in multiplayer where spawning and despawning happens more often across all players. Pooling solves this by recycling objects instead of destroying them.

In PurrNet you can use pooling with networked objects. The way it works is that when an object is despawned or you lost visibility of it, instead of `Destroying` it, we will store it behind the scenes until you try to spawn another of that thing.

To can enable pooling on your network prefabs:

<figure><img src="https://3317286851-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FsgxJN58uttGJCEXbBIwp%2Fuploads%2Fgit-blob-c903a1fc0d585388579728e405512d3980e4c567%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

The way to utilize pooling is quite simple with PurrNet, in fact if you ticked the box you are already done. You keep calling `Instantiate` and `Destroy` and we handle it for you.

If you need to reset some data once it get pooled you have an override on your `NetworkIdentities` that gets called for cleanup:

```csharp
protected override void OnPoolReset()
{
    // reset some stuff
}
```

There is one caveat. PurrNet allows pooling of children separately and even partial pooling where a prefab might be constructed partly from pooled parts and partly from instantiated parts. But this does cause one issues which is possible mangling or loss of references. Note that this is only an issue when you are mix and matching prefab parts and parents. To fix this we made a `Reference<>` module available for you and it is meant to be used like this:

```csharp
[SerializedField] private Reference<MeshRenderer> someRenderer;
```

Now your `MeshRenderer` reference will be repaired if it ever breaks.