求值器 A/B 与运行时成本（2026-11-04）

3.1 宿主先建一轮固定输入视图

CLI 的 assemble 为这一轮新建 Vault / ResourceSession，绑定配置与读取能力。批次内首次读取的字节或错误被固定；相同文件的重复请求仍做逻辑记账，但可以复用物理字节、解析 Data 树。

Python 扩展生成 51,225 个物品文档、513 个目录文档，加手写首页。这里得到的是源文本与路由，不是最终 HTML，也不是提前求值后的整站树。

3.2 先分析所有页面，再逐页求值

SSG 先对每页执行前端 lowering、环境/导入组装、Resolve→Shape→Materialize 和具体实例检查，得到：

Analysis：checked Item 树 + diagnostics + CheckedProgram
DocumentHandle：source + environment + 宿主身份

全部文档先分析完，是为了在任意页面读取其它生成文档之前，将这些文档的源码固定进同一个输入视图。不能不考虑这一约束，就把两轮循环机械改成完全独立的流式单页构建。

CheckedProgram 的实例表和记录已经由 Arc 共享；求值入口的 program.clone() 不是复制全部函数实现。Environment 的导入图也有批次缓存。不要把运行时“607 万次调用”理解成“607 万次模块编译”。

3.3 每页 evaluator：先 bind，再 present

checked Item
  └─ bind_content(scope)
       ├─ 复制结构边界
       ├─ 处理 splice 表达式
       └─ 捕获 pending Call / Repeat 中的自由输入
  └─ present(bound forest)
       ├─ 普通节点：展开 children、验证结构
       ├─ Call：present_call → execute → 再 present 返回内容
       └─ Repeat：求 subject、逐项求 body、挂载、累计预算
  └─ 完成的 Item 树 + diagnostics + dependencies

bind 不是纯粹零执行的复制：splice 表达式可求值，其内部严格数据 let 也可读取资源。但 opaque 内容调用和延迟 for 的实现仍在挂载时执行，未挂载内容不会因为做了捕获就被执行。

3.4 execute 的内层逻辑

1. 根据当前 Context 的 transform 得到实际目标，同时保留原语义身份。

2. 求值参数；处理 optional forwarding、类型/约束、fields。

3. Code 调用另建 inputs Scope，传入 children 和 comptime 参数。

4. 查找具体 InstanceRecord；缺失时按需检查，而非每次重新编译模块。

5. 执行 native，或递归解释 checked body。

6. 数据结果检查返回契约；内容结果保留调用边界、挂载 children、附加展开来源。

当前捕获仍然主要通过 capture_expr/capture_call 递归代换：把自由输入写进表达式/Item 副本。scope 和 signature 实验只改其中一部分组织成本，没有把它整体替换为共享代码加最小环境。

3.5 求值不是流水线终点

每页完成后，Analysis 在求值循环中逐项释放；求值树进入 documents: Vec<Document>，保留到整站处理完成。SSG 随后：

• 准备静态资源和模板；

• 利用全站 DocumentIndex 解析链接、embed、HTML registry，生成正文 HTML；

• 建立共享模板值，再以生产策略最多 8 个线程渲染页面模板；

• 将 files/pages 移进 BuildOutput；

• 释放 SSG 临时对象，再释放 Vault / ResourceSession / DataCache。

最终发布文件字节并未在 SSG 返回时销毁；它们已经移动给宿主。没有为了改善数字提前丢掉输出。

3.6 Updated 与 CLI wall 的边界不同

serve 的 Updated 包含组装及其临时对象/Vault 收尾，但不包含静态站点的磁盘 publish。前一个内存站点的替换发生在记录耗时之后，其最后一个 Arc 引用可能在那时或稍后释放。

所以本轮完整 CLI A/B 不能简单改名为 Updated 加速比例；serve 补充组直接读取真实生产报告，但样本和进程顺序少于主实验，结论强度也不同。

3.7 各阶段到底花多久：独立轻量探针

这组只保留阶段/模块计时，不链接深度 evaluator observer 和 global allocator wrapper；SSG 自动销毁顺序不变，所有 metric/edge 记录提前分配。两版各一次 warmup、三次交替正式测量，完整输出核对。以下为该组的均值，不与主 A/B 的中位数混算。

另外 CLI 磁盘发布平均 0.406 → 0.401s，其中完整输出内容比较 0.371 → 0.365s；它不属于组装/Updated，也不是本次加速主来源。轻量探针进程 wall 三次分别为 base 15.005 / 15.012 / 14.978s，combined 13.786 / 13.852 / 13.751s，与无插桩主组量级接近，但仍是独立的 profiling-feature 诊断二进制。

该诊断组观察到组装少 1.201s，其中求值少 1.009s，约 14.0%，收尾少 0.176s；其它阶段基本不变。这里说明收益主要落在何处，不把这几个差值硬凑成主组的 1.288s。

收尾内，SSG 尾部为 1.378 → 1.214s，Vault 为 1.681 → 1.669s。仍不应把每个 Drop 标签都解释成对象自身固有成本；此前已证明 allocator 历史和记账分配可改变慢路径落点。本次关键是总组装和总进程都确实缩短，而不是把销毁移出计时。

系统噪声没有隐藏

36 个正式进程合计记录 106 次 major fault，单进程最多 30 次；所有样本均保留。scope 和 present 的区间跨零，所以不把约 1% 的点估计当稳定收益。这批数据足以支持 instance / signature 的当前工作负载收益，却不足以支持“父链环境一定更快”等普遍判断。

对 Arc 深拷贝假设的修正

观察 Arc::unwrap_or_clone 的 forest 消费边界：

• strong count 为 1：8,284,177 次；

• strong count 大于 1：1,539 次，占 0.0186%。

因此不能再把当前主要成本解释为“每次拿到 Arc 内容都因共享而深拷贝”。绝大多数这些边界可以直接取得所有权。

这个计数不覆盖所有 clone/COW：capture_expr 中显式复制的 Content forest、Arc::make_mut 的 origin 处理等不在该分支计数里。正确结论是限制一个具体假设，而不是宣称内容复制都不存在。

6.1 整个 Rust CLI 的公共 allocator API 事件

独立 interposer 将调用转发给同一个 glibc allocator，不改变策略；按可执行文件路径排除 Python。表中不含 libc 内部自行分配、aligned 入口和 constructor 激活之前的事件。

这批 interposer 进程耗时 16–18s，明显有额外开销，不用它们的 wall 算加速。请求字节是多次分配的累积流量，realloc 计完整新大小；24.189GB 不代表同时占用 24GB，更不代表复制过同样多字节。

很有说明力的反例是 present：少请求约 2.886GB，单独 wall 收益却未被本次样本确认。分配字节、分配次数、真实执行时间不是线性关系。

6.2 evaluator 内部，按最内层范围归属

另一组 Rust System wrapper 仅统计 evaluator 内部，固定数组记账。它与上面的整进程 C API 观察器是不同边界，不应要求两者总量相等。

base 内部合计 260.985 百万次、17.797GB；combined 为 218.044 百万次、13.428GB。

这些是 Self 分配事件，子操作已记到子范围，避免父子重复累加；不是内存保留对象图，也不是某个 Rust 类型的分配总数。例如 arguments 包含实际 target、参数求值之外的准备、fields 和 Code inputs 等组织工作，不能把全部 41 百万事件都叫作字典分配。

观察器开销有多大

即使 evaluator 细分采样关闭，仍链接深度 observer 的 base-probe wall 就是 16.259s，而普通版中位数 14.989s，约高 8.5%；combined 也有相近量级差异。因此这一组只用于解释内部组织，不拿其 stage 秒数当无插桩真值。阶段图采用另一个不链接该 allocator/高频 observer 的轻量补充组。

RSS 没有随分配流量明显下降

每个普通版本另测两次 Rust PID VmRSS，25ms 采样；不把这些进程纳入主 A/B：

结论不是“省了 18% 内存”，而是“少了 18% 请求字节流量，峰值 RSS 基本没变”。 最终仍保留相同的 4,273,237 个 Item；仅这些节点的 344B 内联布局就约 1.369 GiB，尚未计其拥有的字符串、容器、Data、模板/输出及 allocator 驻留页面。

本轮没有 compact Item、改变整站保留策略或真正共享最终树。减少短命分配和深复制并不自动减少高峰时同时存活的数据，也不保证 allocator 向 OS 归还更多页面。

真实 Updated

重建中位数少约 1.564s、11.25%，方向与主 CLI A/B 一致；但只有两个顺序运行的 serve 进程，首次重建明显慢于后两次，不把 11.25% 当比 8.53% 更精确的普遍加速结论。所有 Updated 都报告 51,739 页，写回只发生在输入副本且不改变文件内容。