Skip to content

Add a reproducible benchmark suite and publish the results#26

Merged
jdatcmd merged 1 commit into
masterfrom
perf-chapter
Jul 6, 2026
Merged

Add a reproducible benchmark suite and publish the results#26
jdatcmd merged 1 commit into
masterfrom
perf-chapter

Conversation

@jdatcmd

@jdatcmd jdatcmd commented Jul 6, 2026

Copy link
Copy Markdown
Collaborator

The first published performance numbers for the modernized PL/php, with the suite committed so anyone can rerun them (sh bench/run.sh).

Benchmark PL/php PL/pgSQL PL/Perl
Scalar math 58.8k 60.0k 57.9k
String ops 43.4k 44.0k 46.3k
SPI loop, 1000 rows 4.7k 8.6k 2.7k
10 SPI stmts/call 23.5k 26.0k 18.7k

Headlines: within a few percent of PL/pgSQL on computation (call overhead dominates, not the interpreter), 1.75× faster than PL/Perl on row loops, and between the two on repeated SPI (both PL/php and PL/Perl pay the subtransaction that makes their errors catchable).

doc/benchmarks.md includes the analysis, honest methodology, and a "tried and rejected" section: per-result column-key interning measured as a no-op (the row-loop cost is per-cell value conversion), so it was dropped instead of merged — the plausible future fast path (binary Datum conversion for common scalars) is recorded for whoever picks it up.

No code changes; docs + bench/ only.

🤖 Generated with Claude Code

bench/run.sh + bench/setup.sql compare PL/php against PL/pgSQL and
PL/Perl on four workloads (scalar math, string ops, an SPI loop over
1000 rows, repeated small SPI statements) via pgbench, with identical
logic in each language.  doc/benchmarks.md publishes the numbers and
their reading: scalar/string work is call-overhead-bound and all
three languages are within a few percent; row iteration is PL/pgSQL's
native strength while PL/php still runs 1.75x faster than PL/Perl;
repeated SPI statements carry the subtransaction that makes PL/php
and PL/Perl errors catchable, with PL/php ~25% ahead of PL/Perl.

One optimization was tried and rejected: interning column-name hash
keys per result measured as a no-op (the row-loop cost is per-cell
value conversion, not key handling), so it was dropped rather than
kept as complexity without benefit.  The document records that, and
the plausible future fast path (binary Datum conversion for common
scalars).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@jdatcmd jdatcmd merged commit 0cc7352 into master Jul 6, 2026
12 checks passed
@jdatcmd jdatcmd deleted the perf-chapter branch July 6, 2026 05:08
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.

2 participants