Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions _config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -252,6 +252,9 @@ navigation:
libraries/radpdfprocessing/formats-and-conversion/pdf/pdfstreamwriter:
title: PdfStreamWriter
position: 2
libraries/radpdfprocessing/formats-and-conversion/pdf/expandablememorystream:
title: ExpandableMemoryStream
position: 3
libraries/radpdfprocessing/formats-and-conversion/plain-text:
title: Plain Text
position: 0
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
---
title: ExpandableMemoryStream
page_title: ExpandableMemoryStream
description: Learn about the segmented, dynamically growing in-memory stream implementation used for large PDF processing scenarios.
slug: radpdfprocessing-formats-and-conversion-pdf-expandablememorystream
tags: pdf, memory, performance, stream, fixed, document, processing, dpl, format, expandablememorystream, large, file, size
published: True
position: 3
---

# ExpandableMemoryStream

ExpandableMemoryStream is a segmented in-memory stream designed for efficient large or parallel PDF operations. Instead of resizing a single contiguous array like a **MemoryStream**, it grows by adding fixed-size blocks as needed—avoiding costly reallocations and Large Object Heap (LOH) pressure. Each block remains untouched once filled, so data isn’t copied during expansion. This block-based approach keeps allocations small and predictable, reduces GC overhead, and supports very large or bursty workloads. When growing, new cleared blocks are appended. When shrinking, only the visible length changes, allowing future reuse of existing memory without additional allocations.

## When to Use

Use it when you need to:

- Build or merge large PDFs fully in memory before saving.
- Combine many pieces where the final size is unknown.
- Run multiple document builds in parallel and want steady, predictable allocations.
- Seek and rewrite parts of the buffered content without triggering array growth copies.

## Example

The following example shows two common ways to load a large PDF document into memory before further processing. The first approach constructs the stream directly from a byte array and passes an explicit segment size (bufferSize). The second approach creates an empty instance and copies a file stream into it. The constructor's second parameter (bufferSize) is optional and defaults to 1,000,000 bytes (1 MB). You can omit it unless you want a different segment size.

<snippet id='libraries-pdf-formats-and-conversion-expandablememorystream-implementation'/>

In both cases the segmented internal structure avoids reallocating a single large contiguous buffer, helping performance and memory stability for very large PDF files.

## See Also

* [PdfFormatProvider]({%slug radpdfprocessing-formats-and-conversion-pdf-pdfformatprovider%})
* [RadFixedDocument]({%slug radpdfprocessing-model-radfixeddocument%})