scratch-buffer-strategy

The best way to allocate a scratch buffer on a hot path is to select the cheapest valid strategy based on size and lifetime, using a decision tree across stackalloc, BufferScope, and ArrayPool renting.

Use stackalloc for small, short-lived buffers to avoid allocation overhead, and switch to ArrayPool renting when buffer sizes exceed safe stack limits, applying crossover thresholds to determine the exact switch point.

SkipLocalsInit improves scratch buffer performance by skipping the automatic zeroing of local variables, reducing overhead for stackalloc buffers when the initial zero values are not required by the hot path logic.

Yes, the BufferScope stack-then-pool fallback strategy works across net481 and net10, providing cross-framework memory cost considerations and thresholds to safely transition from stack allocation to pooled arrays.

The primary limitation of stackalloc for variable buffer sizes is the risk of stack overflow, requiring a maximum size threshold to determine when you must fall back to ArrayPool renting for hot path safety.