Performance validation results

KillerPDF 1.8.2 through 1.8.4 release benchmarks#

Five measured open/save passes were recorded for each release. These are separate release sessions, not an alternating same-session comparison.

Version 1.8.3 saved 1,485 additional files without losing any previously successful input. Version 1.8.4 reproduced every 1.8.3 outcome and diagnostic detail. All three releases recorded zero crashes and timeouts in the separate damaged-file safety collection. See the 1.8.2 release record and the reports and measured runs for 1.8.3 and 1.8.4.

The 1.8.4 regression median was 13.7% longer than the separately recorded 1.8.3 session, while standards was 0.5% shorter and stress was 6.4% longer. The 1.8.3 record used a framework-dependent payload and the official 1.8.4 portable release contains a self-contained .NET 10.0.11 payload. The two releases were not rerun in alternating passes, so the difference is not isolated to application code.

KillerPDF 1.8.1 compared with 1.8.0#

Benchmark date: 2026-08-29

KillerPDF 1.8.1 completed the shared 2,236-file batch-resave workload in a median 7.057 seconds, compared with 7.015 seconds for KillerPDF 1.8.0. The 0.6% throughput difference is within ordinary run-to-run variation and far below the 10% slowdown threshold that requires investigation.

This is a regression benchmark for KillerPDF's real batch-resave path. It is not a claim that one PDF engine will be faster for every document or workload.

Builds under test#

Both executables reported their expected product versions. The 1.8.1 candidate used the same installed-payload build shape as the official 1.8.0 application.

Test system#

Corpus#

The input was the same 2,236-file public conformance subset used for the 1.8.0 release benchmark. Keeping the input fixed makes the two runs directly comparable.

The shared input contains public veraPDF, Isartor, and TWG conformance files. The same input directory was supplied to both versions for every run.

Method#

1. Verify that both executables report the intended final product versions.
2. Verify the release asset hashes and count the input PDFs recursively.
3. Give each version one unmeasured warmup run.
4. Run each version five measured times.
5. Alternate which version runs first to reduce ordering bias from caching, machine temperature, and background activity.
6. Use a fresh output directory for every run.
7. Record elapsed wall-clock time, successful output count, process exit code, and files processed per second.
8. Compare the median of the five measured runs instead of selecting the best run.

Every measured run processed all 2,236 files and returned exit code 0.

Results#

The raw measurements are preserved in benchmarks/1.8.1/benchmark-results.csv, with the calculated medians in benchmarks/1.8.1/benchmark-summary.csv.

KillerPDF 1.8.0 compared with 1.7.5#

Benchmark date: 2026-08-28

KillerPDF 1.8.0 completed the shared 2,236-file batch-resave workload in a median 10.013 seconds, compared with 16.167 seconds for KillerPDF 1.7.5. That is a 38.1% reduction in elapsed time. Median throughput increased from 138.31 to 223.32 files per second.

Builds under test#

The downloaded 1.7.5 executable matched the digest published for the v1.7.5 GitHub release asset. Both executables reported their expected final product versions.

Corpus note#

KillerPDF 1.7.5 could not process the PDF 2.0 files in the full 2,907-file corpus, so those files were excluded from both runs to keep the comparison equivalent.

Results#

The raw measurements are preserved in benchmarks/1.8.0/benchmark-results.csv, with the calculated medians in benchmarks/1.8.0/benchmark-summary.csv.

Reproducing the benchmark#

Benchmark-Versions.ps1 runs the complete warmup, alternating measurement, logging, cleanup, and summary process. Run it from PowerShell with two KillerPDF executables and one shared input tree:

.\Benchmark-Versions.ps1 `
    -BaselineExe 'C:\path\to\KillerPDF-previous.exe' `
    -CandidateExe 'C:\path\to\KillerPDF-current.exe' `
    -InputDirectory 'C:\path\to\shared-corpus' `
    -OutputDirectory "$env:USERPROFILE\killerpdf-benchmark\measured" `
    -Runs 5 `
    -BaselineLabel 'KillerPDF previous' `
    -CandidateLabel 'KillerPDF current'

The output directory must be inside the current user's profile. The script creates and removes only its own output-* run directories. It keeps the per-run logs, benchmark-results.csv, and benchmark-summary.csv.

For a useful comparison, close other demanding applications, keep the machine on the same power plan, use the same corpus and storage device, and do not compare absolute numbers from different computers. The relative change between two builds measured in the same session is the result that matters.

Release baseline#

For each final release:

1. Compare the previous official release with the proposed final build.
2. Use the same machine, corpus, run count, and method.
3. Save the raw CSV files under validation/benchmarks/<version>/.
4. Add the new release result to this report.
5. Investigate a median slowdown of 10% or more before release. A slowdown is not automatically a failure, but it must be understood and documented.