Benchmarks

The rows where @reportwright/pdf is faster than every JavaScript library that produced a valid file. Shorter bar is faster; every number links to its GitHub Actions run.

Source: the ReportWright QA suite, run 38317309719 (2026-10-12, ubuntu-latest, 4 vCPU), the 1.0 release measurement. It measured @reportwright/pdf 0.1.0-beta.15 from npm, the same code as 1.0.0 (only the version and doc comments changed). Cells are the median wall time from process start to exit (warm invoice: in-process median) · peak RSS, with all contestants interleaved run by run in one job.

Where it does not win

Go and Rust writers are faster

On raw writes, fpdf (Go) and printpdf (Rust) beat us in the same run: plain text 10 pages 77 ms (printpdf) vs our 189 ms (2.46×), 100 pages 129 ms (fpdf) vs 420 ms (3.25×), 10,000-row report 258 ms (fpdf) vs 614 ms (2.38×). On fpdf's own showcase (200 pages × 60 lines) fpdf was 6.39× faster. PDFsharp (.NET) won the warm invoice: 5.6 ms vs 8.5 ms.

JavaScript rows we lose or tie

mupdf.js (WASM) is faster at merge (137 ms vs our 182 ms) and split (112 ms vs 185 ms), and tied a cold one-page invoice (187 ms vs 188 ms). Those rows are left out of the charts above.

Edits: native tools are faster

For merge, split and encryption pdfcpu, qpdf, MuPDF and PDFium are faster (encrypt AES-256: pdfcpu 44 ms vs our 136 ms). Small edits are close to Node's process start-up (about 110 ms). Full table: README.