Merging 100 PDFs (50 pages each, mixed text and images) into a single 5,000-page output. Measured with PDFluent, iText 9, and Apache PDFBox.
| Library | Time (ms) | Peak RAM (MB) | Output size (MB) | Notes |
|---|---|---|---|---|
| PDFluent 0.9 (Rust) | 312 | 48 | 187 | |
| iText 9.1 (Java) | 2,840 | 412 | 191 | Includes JVM startup (~900 ms) |
| Apache PDFBox 3.0.1 (Java) | 4,210 | 534 | 195 | Includes JVM startup (~900 ms) |
Note: These numbers are internal estimates based on pre-release builds of PDFluent and reflect the expected performance profile of a native Rust implementation compared to JVM-based libraries. We will publish verified benchmarks with reproducible methodology at general availability. The directional differences (Rust has no GC pauses, no JVM cold start, lower memory baseline) are well-established and will hold in production.
Test corpus: 100 PDFs generated from a real-world document template. Each PDF has 50 pages with a mix of text paragraphs, tables, and one embedded JPEG per page at 150 DPI. Total input: ~210 MB.
Task: Merge all 100 files into a single PDF in page order. No optimization passes, no re-compression.
Environment (planned): AWS c6i.2xlarge (8 vCPU, 16 GB RAM, Linux 6.1 kernel). Single-threaded execution. JVM heap: 4 GB. 10 warm-up runs discarded, 50 timed runs averaged.
JVM startup: iText and PDFBox estimates include JVM cold start (~900 ms). In a long-running JVM process the library-only times would be lower.