We ran the same PDF operations inside real Chromium…
0 reactions
We ran the same PDF operations inside real Chromium, Firefox and WebKit — WebKit was 2.4× faster than Chrome at some of them. Full reproducible harness .
I maintain a client-side file converter, and we publish benchmark numbers
for the PDF operations we ship. After a reviewer pointed out that numbers
nobody can rerun are just marketing, we open-sourced the entire harness:
https://github.com/jddelia/filemorf-lab
What makes it worth a look even if you don't care about the product:
The corpus is byte-reproducible. Test PDFs are generated from seeded
pseudo-random text with pinned metadata — run the generator on your
machine and you get the identical SHA-256s committed in the repo. No "we
tested on some files we can't share."
Correctness gates run before timing. Outputs must parse, page counts
must be exact, ZIP entries must all be present — verified on an untimed
run first, so a fast garbage result fails instead of winning.
Real engines via Playwright, timed in-page with performance.now (), not
through the driver.
Cross-engine results that surprised me (median of 30 runs, M2 Pro,
milliseconds):
Merge 50 PDFs — Chromium 37.5; Firefox 60.5; WebKit 24
Stamp page numbers on 100 pages — Chromium 36.7; Firefox 54; WebKit 15
Watermark 100 pages — Chromium 36.5; Firefox 54; WebKit 14
ZIP 50 PDFs — Chromium 5.9; Firefox 4; WebKit 11
WebKit wins big on pdf-lib's draw-and-save paths and then loses on ZIP.
And everything is fast enough that for files like these, the upload to a
server would cost more than the entire computation — which is the argument
for doing this work client-side in the first place.
Three commands to get your own numbers: npm ci, npm run corpus,
npm run bench. Would love PRs with dated results from other hardware,
and criticism of the methodology — limitations are listed in the README
(synthetic text-only corpus, structural not visual verification).
#programming #js #technology #dev
I maintain a client-side file converter, and we publish benchmark numbers
for the PDF operations we ship. After a reviewer pointed out that numbers
nobody can rerun are just marketing, we open-sourced the entire harness:
https://github.com/jddelia/filemorf-lab
What makes it worth a look even if you don't care about the product:
The corpus is byte-reproducible. Test PDFs are generated from seeded
pseudo-random text with pinned metadata — run the generator on your
machine and you get the identical SHA-256s committed in the repo. No "we
tested on some files we can't share."
Correctness gates run before timing. Outputs must parse, page counts
must be exact, ZIP entries must all be present — verified on an untimed
run first, so a fast garbage result fails instead of winning.
Real engines via Playwright, timed in-page with performance.now (), not
through the driver.
Cross-engine results that surprised me (median of 30 runs, M2 Pro,
milliseconds):
Merge 50 PDFs — Chromium 37.5; Firefox 60.5; WebKit 24
Stamp page numbers on 100 pages — Chromium 36.7; Firefox 54; WebKit 15
Watermark 100 pages — Chromium 36.5; Firefox 54; WebKit 14
ZIP 50 PDFs — Chromium 5.9; Firefox 4; WebKit 11
WebKit wins big on pdf-lib's draw-and-save paths and then loses on ZIP.
And everything is fast enough that for files like these, the upload to a
server would cost more than the entire computation — which is the argument
for doing this work client-side in the first place.
Three commands to get your own numbers: npm ci, npm run corpus,
npm run bench. Would love PRs with dated results from other hardware,
and criticism of the methodology — limitations are listed in the README
(synthetic text-only corpus, structural not visual verification).
#programming #js #technology #dev
| 1,000 mlx | |
| 1 | |
| 0 |