企业官网建设流程全解析

• 编程语言
• AI Agent
• 编译器
• CLI
• 人工智能

导读

本文围绕 BAML 语言内置基准测试工具 speedtest 中的一个核心负载——call-chain-100x10k——展开，剖析它的负载结构、模板化生成机制、跨语言一致性校验与自适应的计时方法论。读完本文，你将掌握如何读懂 speedtest workload 文件、如何单独运行这个百万次调用链基准、以及如何把它与 Python/Node/Bun 的等价实现做横向对比。

call-chain-100x10k 属于compute（纯计算）类别，用于压测 BAML 运行时在深调用链下的函数调用开销：100 层递归深度 × 10000 次外层循环，总计恰好 100 万次函数调用，是评估 BAML 函数调用机制（栈帧压入/弹出、调用链跳转）性能的关键负载。

一、workload 文件的整体结构

BAML speedtest 的每个负载都是一个 Markdown 文件，位于 baml_language/tools/speedtest/workloads 目录下，按类别分子目录存放（compute、string、classes、concurrency、interfaces等）。每个文件遵循统一的四段式约定：

• # <category>::<name>：首行标题即负载的唯一名称，目录名作为类别（category）；
• ## eval-setup：一段可执行的 Python 代码，负责程序化生成三种语言的测试源码（通过字符串模板）；
• ## BAML/## Python/## Typescript：三份源码块，其中通过$$变量名引用 eval-setup 中定义的变量，运行前被展开为真实源码。

以 call-chain-100x10k 为例，其标题是compute::call chain 100x10k，即类别compute、名称call chain 100x10k，其中 "100x10k" 表示 100 层调用链、10000 次循环。

eval-setup 的模板机制

call-chain-100x10k 的 eval-setup 通过三个 Python 循环分别生成 BAML、Python、JavaScript 三份等价的测试程序：

baml_lines = [] for i in range(99): baml_lines.append(f"function f{i}(n: int) -> int {{ f{i+1}(n + 1) }}") baml_lines.append("function f99(n: int) -> int { n }") baml_lines.append(""" function main() -> int { let s = 0; for (let i = 0; i < 10000; i += 1) { s += f0(0); }; return s; }""") baml = "\n".join(baml_lines)

生成逻辑非常直观：

• 生成 100 个函数f0~f99，其中f{i}调用f{i+1}(n + 1)，形成一条从f0到f99的 100 层调用链；
• 链的终点f99(n)直接返回n（终止条件）；
• main内用for (let i = 0; i < 10000; i += 1)循环 10000 次，每次从链头f0(0)开始完整走完 100 层调用并累加结果。

同理，Python 与 JavaScript 版本也生成完全等价的f0~f99链与 10000 次循环，作为 BAML 的对照实现。

模板解析与展开的实现

loader.py 是这套机制的解析器：它用正则^##\s+([\w-]+)\s*\n```\w*\n(.*?)```提取各代码块，用exec()执行 eval-setup 生成命名空间，然后通过自定义的_DDTemplate（继承string.Template，分隔符改为$$而不是$，从而让$在源码里保持字面量）对$$baml、$$python、$$js做安全替换。因此，## BAML块中的$$baml会在加载时被展开为 100 个函数定义加 main 的完整 BAML 源码——本文后续展示的 BAML 程序即为展开后的实际负载。

二、测试负载的语义：100 层调用链 × 10000 次 = 100 万次调用

展开后的 BAML 负载等价于下面的程序（节选前几个函数）：

function f0(n: int) -> int { f1(n + 1) } function f1(n: int) -> int { f2(n + 1) } # ... 中间函数依此类推 ... function f98(n: int) -> int { f99(n + 1) } function f99(n: int) -> int { n } function main() -> int { let s = 0; for (let i = 0; i < 10000; i += 1) { s += f0(0); }; return s; }

从语义上分析这个负载的测量目标：

• 单次链走完的结果：f0(0)经 100 层传递后返回0 + 100 = 100，因此s的最终值是100 × 10000 = 1000000；
• 总调用量：外层循环 10000 次 × 每次 100 层调用 =100 万次函数调用。这正是call-chain-100x10k名称的由来；
• 被测重点：与同目录下的 pure-call-1m（100 万次深度为 1 的平凡调用，用于暴露单次调用的固定开销）互补，本负载把每次调用的成本摊薄在 100 层深栈上，重点考察深调用链场景下函数调用机制（栈帧压入/弹出、跨函数跳转、参数传递）的整体吞吐。

展开后的 Python 与 JS 对照实现

eval-setup 同时生成的两份对照源码展开后等价于：

def f0(n): return f1(n + 1) # ... 依此类推 ... def f99(n): return n s = 0 for _ in range(10000): s += f0(0) print(s)

function f0(n){return f1(n+1)} // ... 依此类推 ... function f99(n){return n} let s=0;for(let i=0;i<10000;i++)s+=f0(0);console.log(s);

三份程序在语义上完全等价、输出完全相同，这为后续的跨语言结果校验提供了基础。

三、运行该负载：打包、校验与计时

1. 定位与过滤

speedtest 的入口是 cli.py，默认子命令为run。要单独运行本负载，使用--filter按名称子串过滤（可重复传参）：

# 假设已按项目文档完成依赖安装（python3 + uv 等） python3 -m speedtest run --filter "call-chain-100x10k"

如果需要先编译 release 版baml-cli与baml_pack_host，加--build；只想测 BAML 而不跑 Python/Node/Bun 对照，加--only-baml：

python3 -m speedtest run --build --filter "call-chain-100x10k" --only-baml

2. 打包（pack）阶段

runner.py 会把展开后的 BAML 源码交给baml-cli pack main --file <baml> -o <packed>打包成独立可执行文件。这一步的关键在于：被测对象是打包后的 BAML 程序而非解释器进程，从而把运行时自身的启动开销与函数调用开销区分开。

3. 输出一致性校验

打包完成后，runner 先运行打包产物取得期望输出（应为1000000），再依次运行 Python（python3 -S，-S跳过 site-packages 以减少干扰）、Node 与 Bun 的等价实现，逐一比对输出：

• 输出一致则正常计时；
• 输出不一致则在结果行标注(!)（mismatch），提示负载等价性被破坏。

这段逻辑对应 runner.py 中的get_output与跨语言checks循环。也就是说，如果三份源码在生成或展开环节不一致，该负载的结果会被显式标记，从机制上保证了跨语言对比的有效性。

4. 计时方法：自适应采样

默认采用自适应计时（criterion 风格，见 runner.py）：

1. 先跑3 次预热（丢弃，用于热 OS 缓存与 CPU 调度）；
2. 依据预热的中位单次耗时估算样本数，目标是用约 5 秒（--measurement-time可调）填满采样；
3. 样本数被夹在[min_samples=5, max_samples=100]之间；
4. 汇总每次运行的中位数（median）、标准差与样本数，输出格式如3.2 ms ± 0.1 ms (37 samples, min=..., max=...)。

也可用--runs N切换为固定 N 次采样的模式。结果表会按类别分组，输出baml、python3、baml/py（比值）、node、bun等列。

四、结果持久化与基线对比

每次运行结束后，结果被写入 storage.py 管理的目录（默认~/.speedtest/）：

• runs/<YYYYMMDD-HHMMSS-commit>/meta.json：每一次运行的完整数据（含负载源码、各 runner 的 med/sd/times、CLI 版本与 VCS 信息）；
• baselines/<branch>/latest与last：自动滚动维护的“最新/上次”基线符号链接；
• baselines/<branch>/<tag>：通过--tag <name>手动打标的基线。

运行结束后终端会提示对比命令：

speedtest compare <branch> <other-branch>

compare.py 会按类别输出 Markdown 表格，列出每个负载（含call chain 100x10k）在两个基线间的耗时变化百分比，并依据显著性标记（统计显著性 + 绝对变化 > 5%）对结果标注*（显著）或~（值得注意），变化方向用:arrow_down:/:arrow_up:表示；若负载源码在两个基线间发生变化，还会附加(src changed)提示，避免把源码变更误判为性能回归。

五、在 compute 家族中的定位与配套设施

与 call-chain-100x10k 同处 compute 目录的负载形成了一个“调用开销测试谱系”：

其中 pure-call-1m.md 的注释明确说明了二者分工：“深度为 100 的 call-chain-100x10k 把每次调用的成本摊薄在深栈上；而 pure-call-1m 不摊薄——它是调用开销的‘显微镜’”，两者互为 speedtest 的孪生负载。

与 Rust 基准套件的衔接

export_baml.py 会把所有 workload 的展开后 BAML 源码以{"name", "category", "baml"}的 JSON 数组形式输出到 stdout，让 Rust 侧的基准套件（crates/baml_tests）直接复用tools/speedtest/workloads/下的负载作为 CodSpeed 基准，无需重复实现.md解析与$$模板逻辑：

python3 export_baml.py [workloads_dir]

因此，call-chain-100x10k 既能在 Python 侧通过speedtest run本地运行，也能作为 CodSpeed 基准进入 Rust 侧的持续性能回归监控，同一份负载定义被两套设施共用。

六、实际使用建议

• 单独验证该负载：python3 -m speedtest run --filter call-chain-100x10k，输出应出现compute类别下的call chain 100x10k行；若显示(!)标记，说明三语言实现输出不一致，需要检查 eval-setup 生成逻辑；
• 只测 BAML：--only-baml可跳过 python/node/bun 探测与运行，加快迭代；
• 性能回归对比：优化运行时后先speedtest run --tag v2，再用speedtest compare <branch>/latest <branch>/v2查看该负载的百分比变化与显著性标记；
• 深挖热点：--profile需要samply在 PATH 中，配合 profiling 模式的 baml-cli（--profile-baml）可为该负载采集 CPU profile，定位调用链热点。

结语

call-chain-100x10k 是理解 BAML 运行时函数调用性能的一个标准入口：它以 100 层 × 10000 次循环构成 100 万次调用，与pure-call-1m一深一浅互为镜像；同时它的 workload 文件完整展示了 speedtest 的“eval-setup 生成 +$$模板展开 + 跨语言输出校验 + 自适应计时 + 基线对比”全流程。借助--filter、--only-baml、compare与export_baml.py，你可以把它既当作本地微基准，也接入持续性能监控，量化 BAML 调用机制在深调用链场景下的每一次演进。

• 编程语言
• AI Agent
• 编译器
• CLI
• 人工智能