The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →For high-throughput .NET APIs, stackalloc, Span<T>, Memory<T>, and pools are not interchangeable ways to make code faster. Choose based on how long data must live, who owns it, and whether measurements show allocation pressure is affecting your workload. .NET 10 also gives the JIT more opportunities to move certain non-escaping arrays to the stack, but that optimization is not guaranteed.
Start with the lifetime and ownership
The useful distinction is not simply “stack versus heap.” First ask how long the data needs to live and who is responsible for its storage. A span is a borrowed view over contiguous data, not an owner. Memory can travel through asynchronous code, but it does not own its backing storage by itself. Pools reuse storage or objects across calls, which means their lifecycle must be managed explicitly.
As an Amazon Associate I earn from qualifying purchases.
| Choice | Best fit | Lifetime and ownership | Main concern |
|---|---|---|---|
Span<T> |
Synchronous work on a contiguous region | A view; the underlying storage belongs to something else | Cannot be stored in an ordinary class field or carried across an async suspension |
Memory<T> |
A buffer that must be retained or used in asynchronous work | A view that can be stored; the backing storage still needs a clear owner | Do not confuse a storable view with ownership or disposal responsibility |
stackalloc |
Small, bounded scratch data used within a method | Stack storage is reclaimed when the method returns | Stack availability varies, and contents start uninitialized |
ArrayPool<T> |
Repeated array buffers whose allocation and collection create measured GC pressure | The renter must return the array exactly once | Returned arrays may be larger than requested; missing a return harms reuse |
ObjectPool<T> |
Expensive-to-initialize objects that are predictably reused | The pool retains objects between uses; callers need a reset policy | Limits retained objects, not necessarily the number allocated |
Use Span<T> for synchronous buffer work
Span<T> lets a method work over a contiguous region without requiring a new array for every operation. The region could be an existing array, stack-allocated storage, or another compatible buffer. Because a span is a view, a method can slice or process data without taking ownership of the underlying memory.
Its lifetime restrictions are deliberate: a span cannot be stored in an ordinary class field or survive an asynchronous suspension. Use it for parsing, formatting, or other work that can finish synchronously while the referenced storage remains valid. Microsoft’s memory and span guidance explains the distinction between these types and their supported lifetimes.
#1 Best Overall
Use Memory<T> when work crosses an async boundary
When a buffer must be held by an object or passed through asynchronous work, Memory<T> is the appropriate view. It can be stored and used in async flows, unlike Span<T>. But Memory<T> does not make the data its own: the code still needs to know who owns the backing storage and how long it remains valid.
If an API accepts IMemoryOwner<T>, it accepts ownership responsibility. The recipient must dispose the owner or transfer that responsibility explicitly. For rented memory, failing to dispose the owner can leak the buffer from the pool or otherwise degrade performance. Make this transfer visible in the API contract and control flow rather than treating an owner as an ordinary view.
Use stackalloc only for small, bounded scratch buffers
stackalloc is useful when a method needs a small, temporary block and can establish a conservative upper bound. Stack space is limited and varies by environment; a large or input-sized allocation can exhaust it. The allocated contents are undefined until initialized, so fill every element that the code reads.
Span<byte> scratch = stackalloc byte[128];
scratch.Clear();
// Use scratch synchronously within this method.The bound in this example is illustrative, not a universal safe size. Choose a limit appropriate to the method and runtime, and use another storage strategy when the required buffer can be larger.
Rank #3
Do not put stackalloc inside a loop: stack space is reclaimed when the method returns, not at the end of each iteration. Microsoft’s C# stackalloc reference recommends allocating outside the loop and reusing the block inside it.
Rent repeated arrays with a guaranteed return path
ArrayPool<T> can reduce repeated array creation and collection when profiling shows that transient buffers contribute meaningfully to GC pressure. Rent the buffer for the required duration, use only the portion needed, and return it in a finally block so exceptions do not skip cleanup:
byte[] buffer = ArrayPool<byte>.Shared.Rent(requiredLength);
try
{
// Use only buffer.AsSpan(0, requiredLength).
}
finally
{
ArrayPool<byte>.Shared.Return(buffer);
}This pattern assumes the array is returned exactly once and is not used afterward. A rented array may be larger than the requested length, so track the valid length separately rather than treating the full array as usable data. Follow the API’s data-clearing requirements if the buffer held sensitive information.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Pool objects only when reuse is predictable and valuable
ObjectPool<T> is aimed at objects that are costly to initialize and are reused frequently enough to justify their retained state and cleanup rules. Define what must be reset before an object is returned; otherwise one request can leave data or state visible to the next user. ASP.NET Core’s documented example uses IResettable to make reset behavior explicit.
A pool’s retention limit is not a cap on total object allocation: when demand exceeds what is retained, additional objects may still be created. Pooling also keeps objects alive longer, potentially increasing retained memory. Microsoft advises: “Use object pooling only after collecting performance data using realistic scenarios for your app or library.” See the ASP.NET Core 10 object pooling guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Account for ASP.NET Core 10 server memory pools
ASP.NET Core 10 automatically evicts idle memory blocks from the pools used by Kestrel, IIS, and HTTP.sys, including when load is lower. It also adds metrics under Microsoft.AspNetCore.MemoryPool and an injectable memory-pool factory. A custom factory does not inherit the framework’s automatic eviction behavior unless it implements comparable logic. See the ASP.NET Core 10 release notes before replacing or customizing a server pool.
What .NET 10 JIT stack allocation changes
The .NET 10 JIT can stack-allocate certain small, fixed-size arrays when it can prove they do not escape the method that creates them. The documented expansion covers arrays of value and reference types, with escape analysis for local struct fields and delegates. This is an optimization opportunity, not a guarantee that an array allocation in source code disappears. The JIT’s decision depends on the array’s shape and lifetime. See Microsoft’s .NET 10 runtime updates.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteThis JIT work complements rather than replaces source-level choices. A span can express synchronous access to an existing region; a pool can address repeatedly created buffers; neither proves what the JIT will do with a particular array. Check the behavior and performance of the actual target runtime instead of assuming every local array stays on the heap—or that every suitable-looking array is optimized away.
Measure whether an allocation strategy helps
Compare the current implementation with the proposed change using realistic API traffic and the same runtime configuration. Track allocation rate and GC activity alongside throughput, retained memory, and tail latency. A lower allocation count can still be a poor trade if it adds contention, retains too much memory, or makes ownership errors more likely. The Microsoft guidance does not establish a universal allocation or latency reduction for these techniques.
Quick Recap
- Use
Span<T>when synchronous work can borrow a contiguous buffer. - Use
Memory<T>when a view must survive beyond the current synchronous call, and make the backing owner’s lifetime explicit. - Use
stackalloconly for initialized, conservatively bounded scratch data outside loops. - Use
ArrayPool<T>when repeated array churn is measurable, with a return-in-finallypath. - Use
ObjectPool<T>only when expensive objects are predictably reused and reset correctly. - Recheck results on the target .NET version, including .NET 10 JIT behavior.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
