The Temp Blob Stream Sink: Stop Copying In-Memory Buffers.

When generating PDFs, building zip archives, or parsing raw payloads in background tasks, working with “Temp Blob” is standard practice. However, handling streams carelessly can cause silent memory bloat and CPU spikes on the middle Tier.

⚠️ The Problem: Implicit Buffer Cloning.
When a procedure accepts a “Temp Blob” codeunit or InStream variable by value (without var), the AL runtime creates a copy of the underlying memory buffer or stream state for the target execution stack.
Calling TempBlob.CreateInStream(InStream) inside a loop without reusing stream handles repeatedly allocates new memory buffers on the Business Central Server tier. For large files or high frequency loops, this creates unnecessary memory churn and heavy Garbage Collection pressure.

🛠️ The Fix: Pass “Temp Blob” by reference and Keep Stream Allocation outside loops.
Treat stream handles like active I/O pipelines. Pass “Temp Blob” instances using “var” to avoid buffer duplication and instantiate your InStream or OutStream outside execution loops whenever processing fixed buffers.

Why it matters:
➡️ Reduced Server memory: Passing “var TempBlob” eliminates stack buffer duplication
➡️Lower Garbage Collection Churn: Reusing stream references reduces memory allocation pressure on the .NET runtime.
➡️Faster In Memory Execution: Eliminates redundant memory copy operations during large file manipulations.

☣️ The Trap:
✅Stream Mutability: Passing var TempBlob allows the target procedure to alter the source data. Ensure read only procedures, do not call CreateOutStream() on shared references.
✅Position Tracking: When re-reading an InStream across iterations, reset the stream position explicitly rather than reopening the stream.

💡 The Bottom Line:
In Memory buffers are not free. Pass TempBlob by reference, instantiate streams deliberately and keep allocation out of your loops.