Skip to content

Commit 237d087

Browse files
authored
Merge pull request #658 from telerik/yoan/expandable-memory-stream
Document ExpandableMemoryStream.
2 parents ffb6ef9 + d6229fb commit 237d087

File tree

2 files changed

+38
-0
lines changed

2 files changed

+38
-0
lines changed

_config.yml

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -252,6 +252,9 @@ navigation:
252252
libraries/radpdfprocessing/formats-and-conversion/pdf/pdfstreamwriter:
253253
title: PdfStreamWriter
254254
position: 2
255+
libraries/radpdfprocessing/formats-and-conversion/pdf/expandablememorystream:
256+
title: ExpandableMemoryStream
257+
position: 3
255258
libraries/radpdfprocessing/formats-and-conversion/plain-text:
256259
title: Plain Text
257260
position: 0
Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
---
2+
title: ExpandableMemoryStream
3+
page_title: ExpandableMemoryStream
4+
description: Learn about the segmented, dynamically growing in-memory stream implementation used for large PDF processing scenarios.
5+
slug: radpdfprocessing-formats-and-conversion-pdf-expandablememorystream
6+
tags: pdf, memory, performance, stream, fixed, document, processing, dpl, format, expandablememorystream, large, file, size
7+
published: True
8+
position: 3
9+
---
10+
11+
# ExpandableMemoryStream
12+
13+
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.
14+
15+
## When to Use
16+
17+
Use it when you need to:
18+
19+
- Build or merge large PDFs fully in memory before saving.
20+
- Combine many pieces where the final size is unknown.
21+
- Run multiple document builds in parallel and want steady, predictable allocations.
22+
- Seek and rewrite parts of the buffered content without triggering array growth copies.
23+
24+
## Example
25+
26+
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.
27+
28+
<snippet id='libraries-pdf-formats-and-conversion-expandablememorystream-implementation'/>
29+
30+
In both cases the segmented internal structure avoids reallocating a single large contiguous buffer, helping performance and memory stability for very large PDF files.
31+
32+
## See Also
33+
34+
* [PdfFormatProvider]({%slug radpdfprocessing-formats-and-conversion-pdf-pdfformatprovider%})
35+
* [RadFixedDocument]({%slug radpdfprocessing-model-radfixeddocument%})

0 commit comments

Comments
 (0)