誠実なベンチマーク

Spec: ISO/IEC 25010 Spec: ISO/IEC 17025 Evidence: Benchmark-backed

概要

測定方法のないベンチマークの数値は、ほとんど何も語りません。「NextPDF は N ミリ秒でドキュメントをレンダリングする」という記述も、対象ドキュメント、ハードウェア、実行回数、ばらつきが分からなければ意味を持ちません。このページでは、NextPDF がパフォーマンスをどのように測定し、なぜ見出しに掲げる数値ではなくゲートされたシグナルとして報告し、なぜ速度の数値を一切記載しないのかを説明します。

これが重要な理由

パフォーマンスに関する主張は、公表しやすく、同時に最も歪めやすい数値でもあります。多くの場合、それは意図せず起こります。アイドル状態のノートパソコンでの一度だけのウォーム実行、十回の試行のうち最速だった結果、ホットパスでは誰も呼び出さない関数のマイクロベンチマーク。こうしたものはいずれも実際の数値を生み出しますが、あなたのワークロードについては何も予測しません。 Spec: ISO/IEC 25010 は、パフォーマンス効率を、規定された条件のもとで 時間およびスループットのパラメータの範囲内で機能を実行することと定義しています（ISO/IEC 25010, §3.10）。「規定された条件のもとで」を取り除くと、その数値は測定値ではなくなります。それは意味を持たない数字です。

もっと見えにくい失敗もあります。かつては正しかった数値です。ベンチマーク結果を文章に貼り付けた瞬間、その値は固定されます。一方で、コード、ランタイム、ハードウェアは変化し続けます。古くなった「高速」という主張は、単に役に立たないだけではありません。それは誤りであり、しかも気づかれないまま誤りであり続けます。

手短に言うと

パフォーマンスの数値は、その 測定方法 を伴わなければ無意味です。具体的には、入力、環境、実行回数、ウォームアップ方針、ばらつきです。
NextPDF は 反復実行 で測定し、ウォームアップの実行を破棄したうえで、単一のベストケース値ではなく分布を報告します。
リグレッション検出は 統計的 に行います。結果はウェルチの t 検定でベースラインと比較して判定されるため、変化がリグレッションと見なされるには、統計的に有意 であり、かつ 問題となるほど大きい 必要があります。
不安定な環境は、ひそかに平均化されるのではなく 検出されて報告 されます。実行ごとのばらつきが大きい場合、その結果は平均値に埋もれさせるのではなく無効とします。
パフォーマンスは ビルドとともに生成される生きたシグナル として公開され、固定された見出しとして公開されることは決してありません。そのため、このページにはミリ秒の数値が一切登場しません。

NextPDF のアプローチ

エンジンのパフォーマンスゲートは、単一の計時実行ではなく統計的検定です。文書化された手法では、測定対象のスイートを繰り返し実行し、設定された回数分のウォームアップ実行を破棄したうえで、所要時間とメモリの双方について平均、標準偏差、変動係数を計算します。その後、現在の結果をコミット済みのベースラインと比較します。

Repeat Run the measured suite N times under fixed conditions.
Discard warmup Drop the first W runs so cold-start noise is excluded.
Summarise Compute mean, standard deviation, and coefficient of variation for duration and memory.
Test vs baseline Welch's t-test (two-sample, unequal variance) against the committed baseline.
Decide Significant AND effect over threshold → regression. Variance over threshold → unreliable, not a pass. Absolute ceiling breach → hard fail.

NextPDF のベンチマークゲートが合格、失敗、信頼不能を判定する仕組み。反復測定を行い、ウォームアップを除外し、分布を要約したうえで、コミット済みのベースラインに対してウェルチの t 検定を適用します。リグレッションには統計的有意性 AND 実質的な効果量の両方が必要であり、過度なばらつきは判定に平均化されるのではなく信頼不能として報告されます。

この方法を誠実なものにしているのは、三つの性質です。第一に、リグレッションには二つの条件が同時に必要 です。すなわち、統計的有意性（その差がノイズである可能性が低いこと）かつ閾値を超える効果量（その差が問題にするべきほど大きいこと）です。ごくわずかな実際の速度低下が、誤った警報を引き起こすことはありません。ノイズの多いデータの中にある大きな低下が、見逃されることもありません。第二に、不安定性そのものが一つの判定 です。実行ごとの変動が限界値を超えると、ゲートはその環境を信頼不能として報告します。意味のない平均を出して合格とはしません。第三に、さらに 絶対的な上限 が存在します。これは、統計に関係なくビルドを失敗させる厳格な上限値です。これにより、「有意なリグレッションなし」という判定が、すでに遅すぎる結果を見逃す口実になることは決してありません。

これは、信頼に足るあらゆる指標について ISO/IEC 17025 が述べる測定規律です。すなわち、あらかじめ定められた条件 のもとで得られる結果であり、単一環境内での再現性（ISO/IEC 17025, §3.7）と、環境をまたいだ再現可能性（ISO/IEC 17025, §3.5）です。NextPDF のパフォーマンス数値は、「この方法、このベースライン、この実行」という形でのみ意味を持ちます。だからこそ、その数値はこのページの一文ではなく、それを生み出したビルドとともに存在するのです。

このページが数値を一切示さない理由は、ゲートが統計的である理由と同じです。文章中の単一の数値は、二つの誤りを招きます。読者はその数値を、自分のまったく異なるワークロードに対する保証として信じてしまいます。また、その数値はコードが進化するにつれて古くなります。見出しではなく、測定方法とゲートされたシグナルを報告することは、読者の判断を尊重することにつながります。それは読者に、確認なしに受け入れざるをえないものではなく、自分で再実行して検証できるものを与えます。再現できないベンチマークは、ひとつの意見にすぎません。このページは、意見を事実として記載することを拒みます。

証拠が示すこと

Evidence: Benchmark-backed エンジンのベンチマークゲートは、ウォームアップ破棄を伴う反復測定、平均/標準偏差/変動係数による要約、そしてコミット済みのベースラインに対する二標本のウェルチの t 検定を実装し、合格/リグレッション/不安定/絶対上限といった明示的な結果を返します。パフォーマンスベンチマークは、個別に実行可能な専用スイートおよび PHPBench ハーネスとしても存在します。パフォーマンスは推定されるのではなく、意図的に測定されます。

Evidence: Standard-backed 「規定された条件のもとで」は、編集上の慎重さではありません。定義そのものです。 Spec: ISO/IEC 25010, §3.10 は、パフォーマンス効率を規定された時間、スループット、リソースの条件と結びつけています。その条件を伴わない数値は、より弱い測定値ではありません。測定値ですらありません。

Evidence: Standard-backed 再現性と再現可能性の捉え方は Spec: ISO/IEC 17025 に従っています。結果が信頼に足るのは、あらかじめ定められた条件との関係においてのみです。同一環境内の再現性を、環境をまたいだ再現可能性と区別します。自らの条件を述べられないベンチマークは、そのどちらも主張できません。

実践的な例

実務において「誠実」とは、数値ではなく方法の記述として現れます。

<?php

declare(strict_types=1);

// The gate is invoked with its conditions made explicit, e.g.:
//
//   php ci/scripts/benchmark-gate.php \
//       --runs=5 --warmup=1 --testsuite=Unit \
//       --baseline=<committed-baseline>
//
// It then reports, for duration AND memory:
//   - mean, standard deviation, coefficient of variation (the spread)
//   - Welch's t-test p-value and effect size vs the baseline
//   - a verdict: PASS | REGRESSION | UNSTABLE | hard-ceiling FAIL
//
// An honest performance statement is therefore shaped like:
//   "<suite>, <runs> runs (<warmup> warmup), <hardware/runtime>,
//    no statistically significant regression vs baseline <id>;
//    coefficient of variation within bound."
//
// It is NEVER shaped like:
//   "NextPDF is fast" — or a bare millisecond number with no method.

ベンチマークの成果物は、再現可能な方法と判定です。生のミリ秒値は、再導出できる限りにおいて、それを生み出したビルドに属するものであり、再導出できないドキュメントへ書き写すべきものではありません。

よくある誤解

第一の誤解は、ベンチマークとは一つの数値だというものです。ベンチマークとは、分布を生み出す手順 です。数値は、そこから一度取り出したものにすぎません。複数回の実行のうち最良のもの、あるいは一度のウォーム実行を報告することは、楽観的なのではありません。それは別のもの（理想的な条件下でのピーク値）を測定し、それを典型的なパフォーマンスと呼んでいるのです。

第二の誤解は、「統計的に有意なリグレッションなし」が「以前と同じ速さであることの保証」を意味するというものです。それが意味するのは、この実行回数とこのばらつきを前提として、観測された差がノイズと区別できる範囲に収まっている、ということです。これは、範囲が限定された条件付きの言明です。まさにそのため、NextPDF は絶対的な上限を独立した安全装置として保持し、結果を無条件の主張に圧縮することを、自らについても他者に対しても拒みます。

限界と境界

このページは、NextPDF がパフォーマンスを どのように 測定し報告するかを説明します。スループット、レイテンシ、メモリの数値は意図的に一切記載していません。それらは、明示された条件のもとで継続的インテグレーションの成果物から生成される生きたシグナルであり、現在の値はビルドとともに公開されます。ここに転記された数値は条件を欠き、時間とともに古くなります。それこそ、このページが反対しているまさにその失敗です。引用できる安定したパフォーマンス定数は存在しないため、何も引用していません。規律こそが成果物です。

実行回数、ウォームアップ方針、閾値、ベースラインは、エンジンのベンチマーク設定によって管理され、エンジンおよびそのハードウェアとともに変化していきます。この説明と食い違う場合は、その設定が正です。NextPDF は、有利であれ不利であれ、他のいかなるライブラリとのパフォーマンス比較も行いません。同一の明示された条件を伴わないそうした比較は、まさにこのページが拒もうとしている無条件の主張そのものになるからです。

用語集

ベンチマーク — 明示された条件のもとで、測定値の分布を生み出す定義済みの手順。単一の数値ではない。
ウォームアップ実行 — コールドスタートの影響（JIT、キャッシュ、オートロード）が測定結果を汚染しないよう、破棄される最初の繰り返し。
変動係数 — 標準偏差を平均で割った値。実行が信頼できるほど安定しているかを判断するために用いる、単位を持たないばらつきの尺度。
ウェルチの t 検定 — 分散が等しくない場合に使う二標本統計検定。ここでは、結果がノイズを超えてベースラインと異なるかどうかの判定に用いる。
効果量 — 統計的有意性とは別に見た、差の大きさ。NextPDF はリグレッションを宣言する前に、その両方を必要とする。
再現性/再現可能性 — ISO/IEC 17025 に基づき、あらかじめ定められた条件のもとで、単一環境内（再現性）または複数環境にまたがって（再現可能性）結果が一致すること。
絶対的な上限 — 統計的比較にかかわらずビルドを失敗させる、厳格な上限値。