Solving the “Expensive Object” Problem in .NET

Introduction

In modern .NET development we are often told that the Garbage Collector or GC is our best friend. While true on many occassions, event the best friendships have limits. When your applications constantly instantiates and destroys heavy objects, like database connections, network clients or large memory buffers, you are not just writing code, you are creating a bottleneck.

The Hook: The Hidden Cost of “new”

Everytime you execute new HttpClient() or new SqlConnection() you are not just allocating a few bytes of memory, you are often initiating socket connections, handshaking with remote server and setting up complex internal states.

When these objects are discarded, the Garbage Collector must step in to clean up. Under high load, this leads to:

• GC Pressure: At some point the CPU starts spending more time cleaning memory than executing your logic.
• Latency Spike: “Stop-the-world” GC pauses can turn a 10 ms request into 500 ms jitter in a worst-case scenario.

The Concept: Object Pooling vs. Garbage Collection

Instead of “Create -> Use -> Destroy” lifecycle managed by the GC, Object Pooling introduces a “Borrow -> Use -> Return” pattern.

Feature	Garbage Collection (Standard)	Object Pooling (Esox.ObjectPool)
Lifecyle	Objects are created and abandoned.	Objects are pre-created and reused.
Performance	Variable, this depends on GC cycles.	Deterministic O(1) operations, i.e. constant time.
Allocation	High, since there are constant new allocations.	Low, this pattern has relatively stable memory footprint.

Quickstart: Implementing your first ObjectPool<T>

Using EsoxSolutions.ObjectPool, you can transition from resource-heavy allocations to a high-performance pool in just a few lines of code:

using EsoxSolutions.ObjectPool;

var initialResources = new List<MyExpensiveResource> { 
    new(), new(), new() 
};


var pool = new ObjectPool<MyExpensiveResource>(initialResources);

using (var model = pool.GetObject())
{
    var resource = model.Unwrap();
    resource.DoWork();
} 

Line by line:

1. We start by importing the EsoxSolutions.ObjectPool package.
2. Next we initialize the list of resource. Think of MyExpensiveResource as an object which is expensive to instantiate, either because it requires time or memory to set up.
3. Now we can initialize the pool, with the pre-created objects.
4. To retrieve an object we call GetObject() on the pool. This does not return the object itself, but rather a PoolModel<T> which is wraps the object, as it also has a reference to the object pool from which it came.
5. You can use Unwrap() to retrieve the object itself, and use that.

The Magic of PoolModel<T> and IDisposable

The biggest risk with manual pooling is forgetting to return the object leading to a “leaky” pool. EsoxSolutions.ObjectPool solves this using the IDisposable pattern via the PoolModel<T> wrapper.

When you call GetObject() you receive a PoolModel<T>. This wrapper acts a guardian:

1. Unwrap: You call Unwrap() to access the actual resource.
2. Automatic Return: Because PoolModel<T> implements IDisposable, the moment the using block ends, the object is safely pushed back into the pool, so no manual pool.Return(obj) is required.

Key Advantage: High-Performance Reliability

The library is not just a wrapper, it is a kind of engine designed for concurrent environments:

• O(1) Complexity: Both retrieving using GetObject() and returning using ReturnObject() occur in constant time, that is O(1), ensuring your overhead remains zero regardless of pool size.
• Thread-Safety: The pool is built using lock-free ConcurrentStack<T> and atomic operation.
• Modern .NET: Fully optimized for .NET 8, 9 and 10, utilizing C# 14 features, like collection expressions and primary constructors for maximum efficiency.

Conclusion

Mastering memory management in .NET doesn’t mean working against the Garbage Collector—it means knowing when to give it a break. While the GC is an incredible piece of engineering, it shouldn’t be tasked with scrubbing your heavy-duty database connections or massive buffers every few milliseconds. By shifting to an object pooling strategy, you effectively trade unpredictable “stop-the-world” latency for deterministic, O(1) performance.

The beauty of using a tool like EsoxSolutions.ObjectPool lies in its safety. By leveraging the IDisposable pattern via PoolModel<T>, you gain the high-throughput benefits of resource reuse without the classic “leaky pool” nightmares of manual management. Whether you’re optimizing a high-traffic API on .NET 8 or preparing for the next generation of C#, prioritizing deterministic resource allocation is a hallmark of senior-level engineering. Stop treating your expensive objects as disposable—start recycling them, and your CPU (and your users) will thank you.