Skip to content

Benchmarks, because "would SIMD help" cannot be asked without a baseline - #112

Merged
tannevaled merged 1 commit into
mainfrom
a-baseline-to-optimise-against
Oct 6, 2026
Merged

tannevaled merged 1 commit into
mainfrom
a-baseline-to-optimise-against

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

Asked whether go-asmgen or go-simd could make go-pdfkit faster. The
honest first answer is that nobody can tell
, and here is why:

test files benchmarks
render 43 0
reader 22 0
ops 27 0
extract 10 0
opentype 40 0
go-gfx/gfx 55 13

The only measured corner of the stack is gfx, and the only generated SIMD
anywhere in it is gfx/resample — amd64, arm64 and s390x, from go-asmgen.
go-highway is an indirect dependency of both gfx and render: no code of
ours calls it.

Optimising from here would be choosing where to spend effort by guessing, and
the way that fails is well documented in this fleet — a plateau read as
progress, or two errors cancelling inside a proxy measurement.

Five benchmarks, over the paths where the question lives

what it exercises
PagePaths gfx/vector's scanline rasteriser — no SIMD today
PageByScale the same page at 72, 150 and 300 dpi: does cost follow pixels or operators? That is the first thing worth knowing before moving anything into assembly
PageEmpty the fixed cost of opening, laying out and allocating, so the floor is visible beside the work in every other benchmark
PageColourChanges many small fills with a colour change between each — where per-operator cost dominates per-pixel cost

⛔ No numbers are claimed here

This machine is at load average 12–19 with twenty peer sessions on it, and
a number taken under load is a number about the load. The benchmarks exist so
the question can be answered on a quiet machine, with -count=6 and
benchstat, rather than one run against one run.

A smoke run (one iteration each, not a measurement) confirms they execute and
hints at the shape: an empty page costs 2.1 ms of the 3.3 ms a hundred
rectangles cost, so the fixed floor is most of a small page. If that holds when
it is measured properly, the first win is not SIMD at all.

Change to existing code

onePage takes a testing.TB rather than a *testing.T. That is the whole of
it. Coverage is untouched at 100 %.

🤖 Generated with Claude Code

Asked whether go-asmgen or go-simd could make go-pdfkit faster. The honest
first answer is that nobody can tell, and here is why:

    render     43 test files, 0 benchmarks
    reader     22 test files, 0 benchmarks
    ops        27 test files, 0 benchmarks
    extract    10 test files, 0 benchmarks
    opentype   40 test files, 0 benchmarks
    go-gfx/gfx 55 test files, 13 benchmarks

The only measured corner of the stack is gfx, and the only generated SIMD
anywhere in it is `gfx/resample` -- amd64, arm64 and s390x, from go-asmgen.
`go-highway` is an INDIRECT dependency of both gfx and render: no code of ours
calls it.

So optimising now would be choosing where to spend effort by guessing, and the
way that fails is well documented in this fleet: a plateau read as progress, or
two errors cancelling in a proxy measurement.

Five benchmarks over the paths where the question actually lives:

  Paths            gfx/vector's scanline rasteriser, which has no SIMD today
  ByScale          the same page at 72, 150 and 300 dpi, which says whether
                   cost follows PIXELS or follows OPERATORS -- the first thing
                   worth knowing before moving anything into assembly
  Empty            the fixed cost of opening, laying out and allocating, so
                   the floor is visible beside the work in all the others
  ColourChanges    many small fills with a colour change between each, the
                   case where per-operator cost dominates per-pixel cost

⛔ No numbers are claimed here. This machine is at load average 12-19 with
twenty peer sessions on it, and a number taken under load is a number about
the load. The benchmarks exist so the question can be answered on a quiet
machine, with `-count=6` and benchstat, rather than from one run against one
run.

`onePage` takes a testing.TB rather than a *testing.T, which is the whole of
the change to existing code. Coverage is untouched at 100 %.
@tannevaled
tannevaled merged commit 3bb5dcf into main Oct 6, 2026
13 checks passed
@tannevaled
tannevaled deleted the a-baseline-to-optimise-against branch October 6, 2026 14:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant