perf: reduce allocations and copies in load-modify-save path#34
Merged
Conversation
We were only ~1.5x faster than pdf-lib for load → modify → save, which is underwhelming given our architectural advantages. Profiling with bun --cpu-prof showed the bottleneck was allocation churn and unnecessary copying, not parsing or serialization logic. Key changes: - Pre-size ByteWriter buffers using size hints (original PDF length for full saves, estimated output sizes for filters/serializers) to avoid repeated geometric reallocation - Use subarray instead of slice for stream data in the parser — these are zero-copy views into the original PDF bytes which stay alive for the document lifetime anyway - Return the internal buffer directly from ByteWriter.toBytes() when it's already the right size (zero-copy fast path), fall back to subarray instead of slice for the trimmed case - Hoist the trailing-zero regex in formatPdfNumber out of the function body so it isn't recompiled on every call - Route page tree loading through registry.resolve so objects are tracked for modification detection (was using parsed.getObject which bypassed the registry)
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Benchmark ResultsComparisonLoad PDF
Create blank PDF
Add 10 pages
Draw 50 rectangles
Load and save PDF
Load, modify, and save PDF
Extract single page from 100-page PDF
Split 100-page PDF into single-page PDFs
Split 2000-page PDF into single-page PDFs (0.9MB)
Copy 10 pages between documents
Merge 2 x 100-page PDFs
CopyingCopy pages between documents
Duplicate pages within same document
Merge PDFs
Drawingbenchmarks/drawing.bench.ts
Formsbenchmarks/forms.bench.ts
Loadingbenchmarks/loading.bench.ts
Savingbenchmarks/saving.bench.ts
SplittingExtract single page
Split into single-page PDFs
Batch page extraction
Environment
Results are machine-dependent. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Improves performance of the load → modify → save cycle.
Why: We were only ~1.5x faster than pdf-lib for load/modify/save, which is underwhelming given our architectural advantages.
How: Profiling showed the bottleneck was allocation churn and unnecessary copying. This PR:
subarrayinstead ofslicefor stream data in the parser — zero-copy views into the original PDF bytes, which stay alive for the document lifetime anywayByteWriter.toBytes()when it's already the right size (zero-copy fast path), falls back tosubarrayinstead ofslicefor the trimmed caseformatPdfNumberout of the function body so it isn't recompiled on every callregistry.resolveso objects are tracked for modification detection