编程语言AI Agent编译器CLI人工智能【免费下载链接】bamlThe programming language for agents项目地址https://gitcode.com/gh_mirrors/ba/baml点击查看免费下载导读本文围绕 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(ffunction f{i}(n: int) - int {{ f{i1}(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{i1}(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-1m100 万次深度为 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(n1)} // ... 依此类推 ... function f99(n){return n} let s0;for(let i0;i10000;i)sf0(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-bamlpython3 -m speedtest run --build --filter call-chain-100x10k --only-baml2. 打包pack阶段runner.py 会把展开后的 BAML 源码交给baml-cli pack main --file baml -o packed打包成独立可执行文件。这一步的关键在于被测对象是打包后的 BAML 程序而非解释器进程从而把运行时自身的启动开销与函数调用开销区分开。3. 输出一致性校验打包完成后runner 先运行打包产物取得期望输出应为1000000再依次运行 Pythonpython3 -S-S跳过 site-packages 以减少干扰、Node 与 Bun 的等价实现逐一比对输出输出一致则正常计时输出不一致则在结果行标注(!)mismatch提示负载等价性被破坏。这段逻辑对应 runner.py 中的get_output与跨语言checks循环。也就是说如果三份源码在生成或展开环节不一致该负载的结果会被显式标记从机制上保证了跨语言对比的有效性。4. 计时方法自适应采样默认采用自适应计时criterion 风格见 runner.py先跑3 次预热丢弃用于热 OS 缓存与 CPU 调度依据预热的中位单次耗时估算样本数目标是用约 5 秒--measurement-time可调填满采样样本数被夹在[min_samples5, max_samples100]之间汇总每次运行的中位数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-branchcompare.py 会按类别输出 Markdown 表格列出每个负载含call chain 100x10k在两个基线间的耗时变化百分比并依据显著性标记统计显著性 绝对变化 5%对结果标注*显著或~值得注意变化方向用:arrow_down:/:arrow_up:表示若负载源码在两个基线间发生变化还会附加(src changed)提示避免把源码变更误判为性能回归。五、在 compute 家族中的定位与配套设施与 call-chain-100x10k 同处 compute 目录的负载形成了一个“调用开销测试谱系”负载形态测量侧重pure-call-1m100 万次深度为 1 的平凡调用单次调用的固定开销栈帧压入/弹出call-chain-100x10k100 层深链 × 10000 次循环深调用链下的整体吞吐每层调用成本被摊薄fib32-recursive二叉递归 fib(32)递归分支 数值累加的混合场景closure-apply-1m/generic-apply-inferred-1m高阶/泛型调用间接调用与泛型实例化的开销其中 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人工智能【免费下载链接】bamlThe programming language for agents项目地址https://gitcode.com/gh_mirrors/ba/baml点击查看免费下载相关推荐BAML 方法链基准测试深度解读method-chain-100k 工作负载的定位、运行机制与源码实现BAML 方法链基准测试深度解读method chain 100k 工作负载的定位、运行机制与源码实现 method chain 100k 是 BAML 仓库编程语言AI Agent编译器CLI人工智能BAML 函数调用开销基准全解compute::pure call 1m 工作负载与 BEX 引擎逐调用剖析BAML 函数调用开销基准全解compute::pure call 1m 工作负载与 BEX 引擎逐调用剖析 本文深入解析 BAMLBoundaryML面编程语言AI Agent编译器CLI人工智能Quarkdown 内联函数调用Inline Function Call词法分析测试用例驱动的识别规则与实现原理Quarkdown 内联函数调用Inline Function Call词法分析测试用例驱动的识别规则与实现原理 Quarkdown 的核心特性之一是以开发工具CLI上一篇MyViewOfLinuxSystems项目架构进程、文件与套接字的关系下一篇ES8389 xiaozhi-esp32 音频接入指南从接线到出声创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
编程语言AI Agent编译器CLI人工智能【免费下载链接】bamlThe programming language for agents项目地址https://gitcode.com/gh_mirrors/ba/baml点击查看免费下载导读本文围绕 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(ffunction f{i}(n: int) - int {{ f{i1}(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{i1}(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-1m100 万次深度为 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(n1)} // ... 依此类推 ... function f99(n){return n} let s0;for(let i0;i10000;i)sf0(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-bamlpython3 -m speedtest run --build --filter call-chain-100x10k --only-baml2. 打包pack阶段runner.py 会把展开后的 BAML 源码交给baml-cli pack main --file baml -o packed打包成独立可执行文件。这一步的关键在于被测对象是打包后的 BAML 程序而非解释器进程从而把运行时自身的启动开销与函数调用开销区分开。3. 输出一致性校验打包完成后runner 先运行打包产物取得期望输出应为1000000再依次运行 Pythonpython3 -S-S跳过 site-packages 以减少干扰、Node 与 Bun 的等价实现逐一比对输出输出一致则正常计时输出不一致则在结果行标注(!)mismatch提示负载等价性被破坏。这段逻辑对应 runner.py 中的get_output与跨语言checks循环。也就是说如果三份源码在生成或展开环节不一致该负载的结果会被显式标记从机制上保证了跨语言对比的有效性。4. 计时方法自适应采样默认采用自适应计时criterion 风格见 runner.py先跑3 次预热丢弃用于热 OS 缓存与 CPU 调度依据预热的中位单次耗时估算样本数目标是用约 5 秒--measurement-time可调填满采样样本数被夹在[min_samples5, max_samples100]之间汇总每次运行的中位数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-branchcompare.py 会按类别输出 Markdown 表格列出每个负载含call chain 100x10k在两个基线间的耗时变化百分比并依据显著性标记统计显著性 绝对变化 5%对结果标注*显著或~值得注意变化方向用:arrow_down:/:arrow_up:表示若负载源码在两个基线间发生变化还会附加(src changed)提示避免把源码变更误判为性能回归。五、在 compute 家族中的定位与配套设施与 call-chain-100x10k 同处 compute 目录的负载形成了一个“调用开销测试谱系”负载形态测量侧重pure-call-1m100 万次深度为 1 的平凡调用单次调用的固定开销栈帧压入/弹出call-chain-100x10k100 层深链 × 10000 次循环深调用链下的整体吞吐每层调用成本被摊薄fib32-recursive二叉递归 fib(32)递归分支 数值累加的混合场景closure-apply-1m/generic-apply-inferred-1m高阶/泛型调用间接调用与泛型实例化的开销其中 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人工智能【免费下载链接】bamlThe programming language for agents项目地址https://gitcode.com/gh_mirrors/ba/baml点击查看免费下载相关推荐BAML 方法链基准测试深度解读method-chain-100k 工作负载的定位、运行机制与源码实现BAML 方法链基准测试深度解读method chain 100k 工作负载的定位、运行机制与源码实现 method chain 100k 是 BAML 仓库编程语言AI Agent编译器CLI人工智能BAML 函数调用开销基准全解compute::pure call 1m 工作负载与 BEX 引擎逐调用剖析BAML 函数调用开销基准全解compute::pure call 1m 工作负载与 BEX 引擎逐调用剖析 本文深入解析 BAMLBoundaryML面编程语言AI Agent编译器CLI人工智能Quarkdown 内联函数调用Inline Function Call词法分析测试用例驱动的识别规则与实现原理Quarkdown 内联函数调用Inline Function Call词法分析测试用例驱动的识别规则与实现原理 Quarkdown 的核心特性之一是以开发工具CLI上一篇MyViewOfLinuxSystems项目架构进程、文件与套接字的关系下一篇ES8389 xiaozhi-esp32 音频接入指南从接线到出声创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
