You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
perf: reduce allocations and copies in load-modify-save path (#34)
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)
0 commit comments