A result begins with a question
Every study starts with a narrow operational question. The benchmark must compare documented work, not arbitrary syntax. When two variants have different correctness or security properties, the report says so rather than presenting the fastest row as a recommendation.
Fixtures are generated deterministically so the same package can be run again. Host-specific properties—PHP version, operating system, architecture and selected extensions—are captured at generation time and attached to every report.
Warm-up, rotation and repeated samples
Each variant receives a short warm-up before measurement. Measured rounds rotate and reverse variant order to reduce a fixed first-or-last position effect. The suite uses hrtime(true), reports the median, and publishes the 25th and 75th percentile of nanoseconds per operation.
The suite does not pretend that this removes every source of noise. Shared-host activity, CPU frequency scaling, virtualization and filesystem cache state remain possible influences. Raw samples are therefore published instead of hiding uncertainty behind one number.
Publication is generated from data
The benchmark runner writes one machine-readable JSON file and a flat CSV summary. The static-site builder reads those files and creates report pages, tables, accessible charts, a dataset catalog and an environment page.
Narrative sections are maintained as study-specific editorial content. Measurements can change when the suite is rerun, while the research question, semantic warnings and limitations remain reviewable source files.