fixture 设计

设计目标

同一个输入必须到达每个实现，而准备它的代价是否计入测量，必须由声明决定，而不是出于偶然。fixture 把发生在输入上的五件事（生成、标识、复制、准备、重置）分开，使运行器能把每一件都放在时钟的正确一侧。

夹具是一个按数据集 $D$ 和实现 $I$ 应用的小型状态机：

\text{ctx} \xrightarrow{\ \text{materialize}\ } x \xrightarrow{\ \text{clone}\ } x' \xrightarrow{\ \text{prepare}(\cdot,\, I,\, \text{sample})\ } p \xrightarrow{\ \text{run}^n\ } p \xrightarrow{\ \text{reset}\ } \bot .

两个等式表达了运行器所依赖的契约。

隔离。 如果某个实现修改了 $p$ ，下一次准备仍必须看到原始的 $x$ ： $\text{prepare}(\text{clone}(x))$ 不得与 $x$ 共享可变状态。这样每个批次都从相同的状态开始，并且在每个区组中被测量的工作负载都是 $x$ 的同一个函数。
确定性。 $\text{materialize}$ 只是上下文的函数，因此相等的上下文给出相等的输入和相等的指纹： $\text{ctx} = \text{ctx}' \Rightarrow \text{fingerprint}(\text{materialize}(\text{ctx})) = \text{fingerprint}(\text{materialize}(\text{ctx}'))$ 。

运行器对两者都不检查；违反它们会使各区组测量不同的工作负载。

设一次操作的代价为 $c$ ，一次准备的代价为 $a$ 。对于含 $n$ 次操作的批次，运行器报告 $\hat T / n$ ，其中

按批次计入准备工作，测得的是取决于校准所选批次大小的摊销代价；只有按迭代计入，或批次大小固定时，才应计入准备工作。

问题。 各夹具的输入类型、准备后类型和策略各不相同，而且常常在测试中内联编写。选择。 Fixture 是带三个类型参数的函数记录。理由。 trait 需要为每个夹具定义一个类型，并且无法把 id、版本和策略作为值携带。

运行器总是在 prepare 之前调用 clone_input。Fixture::immutable 让两者都成为恒等函数，这对永不修改的值没有代价；可变输入则提供真正的副本。把克隆和准备分开，使夹具可以只复制一次输入并围绕它建立工作区，也使两者各自的代价都可见。

prepare 接收实现 id，因此它可以生成某个实现所期望的布局（打包、转置、填充）。这样准备工作就属于夹具，其计时遵循声明的策略，而不是隐藏在某个实现的负载中。

SetupPolicy 随每个观测（setup_timing）以及在事件流中被记录。读者无需阅读代码就能区分冷启动测量和热态测量。