CodeBurn 性能基线 Phase 0 深度解读：等待路径度量、基准数值与一键复现指南

【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载导读本文围绕 CodeBurn 仓库中的性能基线文档 perf/BASELINES.md 展开系统讲解该项目 Phase 0 性能测试平台harness的定位、每条基线指标的含义与实测数值、以及如何在一台干净机器上用两条命令复现全部结果。读完本文你将掌握 CodeBurn 等待路径wait-path性能度量的完整方法论——从合成语料生成、环境隔离到逐指标解析并能独立复跑基线、对比优化前后数值理解 18 秒历史问题与 250ms p95 目标之间的关系。一、基线从何而来一段 18 秒的历史遗留CodeBurn 是一个跨 37 个 AI 编码工具与 Agent 追踪 token 用量与成本的本地 CLI/桌面工具可通过npx codeburn使用。当用户本地积累了数十 MB 的会话记录后桌面端生成今日概览摘要可能变得很慢。基线文档记录了一个重要的历史实测已安装的 Desktop 0.9.21真实语料2026-08-277 天有用摘要useful summary耗时18286.98 ms约 18.3 秒30 秒空闲之后。这个 18 秒的数字是历史凭证historical receipt并非当前 fixture 的产物——它来自一次未公开的已安装应用审计运行因此无法从本仓库重新推导。它的意义在于明确了性能目标规格目标spec target就绪摘要250ms p95且在代际generation未变化时零原始读取zero raw reads on unchanged generation。也就是说Phase 0 性能平台要回答的核心问题是如何把一次18 秒的 7 天摘要降到250ms p95 的就绪摘要这一数量级并且每次改动前后都能用可复现的数字证明基线的定位在文档中写得很清楚它是在第一次产品改动之前从当前 main 分支钉住pinned的SHA93b7b9a7da02ee77c80ac54264b87358121c5cf7分支perf/harness-phase0日期2026-08-29机器Mac15,14, arm64Node v22.22.3并有一条纪律性规定没有该测试平台产出的前后对比数字的迭代视为不存在An iteration without a before/after number from this harness does not exist。这是整个性能改进流程的准入条件。二、基线表逐行解读每条数字背后是什么基线表记录的全部是等待路径测量wait-path measurements即通过隔离 HOME CLI/serve 子进程实测的耗时文档明确声明它们不是已安装 Desktop/Menu Bar 的 UI 证明。完整基线如下metricfixturecommandmachinenumbernotessession-parse cold (ms p50/p95)scripts/perf/gen-fixture.mjs --target-mb 30隔离 HOMEnode scripts/perf/run-metric.mjs --metric session-parse --home HOMEMac15,14, arm64, v22.22.3, sha 93b7b9a71768.0 / 1791.0MB/s p5015.091fixture_bytes27977201incremental-reparse (ms)生成 30MB fixture 后追加 2 行 JSONL同上--metric incremental-reparse同上463.0同一 inode 追加日常路径period-switch first 7D after load (ms)30MB fixture经serve --stdio--metric period-switch同上120.9索引就绪后的首个 7D18s 凭证的类似物等待路径period-switch first 30D after load (ms)同上同上同上166.3索引就绪后的首个 30D等待路径period-switch 7D warm (ms p50/p95)同上同上同上0.4 / 0.6等待路径已安装 UI 目标仍为 250ms p95period-switch 30D warm (ms p50/p95)同上同上同上0.3 / 0.5等待路径serve ready (ms)30MB fixture隔离 HOME同上同上399.3{ready:true}帧cold-start desktop wait-path (ms p50/p95)30MB fixture隔离 HOME--metric cold-start-cli同上1651.4 / 1729.5status menubar-json --period today --no-timelineUI 未验证cold-start menubar wait-path (ms p50/p95)同上同上同上1510.4 / 1526.0status menubar-json --provider all --period today --no-optimizeUI 未验证refresh proxy (ms p95)30MB fixture隔离 HOME--metric dock-tui-proxy同上211.4hover 是原生 dock此处是载荷复用view-switch proxy (ms p95)同上同上同上121.3period week 请求侧边栏绘制未验证memory RSS after cold load (bytes)30MB fixture隔离 HOME--metric memory同上366460928本次未跑 1h 空闲泄漏检查需传--idle-ms 3600000解读几个关键行session-parse cold1768.0 / 1791.0 ms冷解析 30MB 合成语料fixture 实际字节 27,977,201约 27.98MB吞吐约 15.09 MB/sp50。这是全量解析的下限成本。incremental-reparse463.0 ms在同一 inode 上追加两行 JSONL 后再跑一次。这是日常路径——用户的新会话追加写入原文件而不是重写文件增量重解析应显著快于冷解析。period-switch first 7D/30D after load120.9 / 166.3 ms这是 18 秒凭证的直接类比物——完整语料加载完毕、索引就绪后的首个 7D/30D 摘要等待时间。120.9ms 对比历史 18286.98ms可见加载完成后切周期已不再慢。period-switch warm 7D/30D0.4/0.6 与 0.3/0.5 ms同一周期重复请求几乎零成本说明结果已被缓存、代际未变时无原始读取。cold-start desktop / menubar wait-path1651.4 / 1510.4 ms p50一次性status --format menubar-json的完整 argv 启动等待路径模拟 Desktop/Menu Bar 已 spawn 进程后的等待。两个数字都标注UI 未验证——即不包含窗口显示或菜单栏火焰图标出现的时间。memory RSS366,460,928 bytes ≈ 349.5 MiB冷加载后的常驻内存。泄漏检查需要额外传--idle-ms 36000001 小时空闲观察 RSS 是否增长。三、每个指标是什么 / 不是什么perf/README.md 给出了每个指标的精确定义边界这决定了数字的解读范围Metric命令数字是什么不是什么Cold start (wait-path)--metric cold-start-cli一次性status --format menubar-jsonargvDesktop/Menu Bar 已 spawn已安装窗口显示 / 菜单栏火焰出现Session parse--metric session-parse合成 fixture 的冷解析MB/s 与 ms大型真实语料Incremental re-parse--metric incremental-reparse在同一 inode 追加两行 JSONL 后重跑重写 / inode 变化Period switch--metric period-switch热serve --stdio的 7D/30D p50/p95已安装 Desktop 在真实语料上的 250ms p95Dock/TUI interactions--metric dock-tui-proxyoverview 刷新与视图切换的等待路径Capacity Dock hover原生从不 spawn 该 argv或 TTY TUI 按键Memory--metric memory冷加载后的 RSS可选--idle-ms 3600000打包应用 RSS这套是什么/不是什么的对照是性能工程中防误导的关键每个数字都明确了自己的证据边界读者不会被等待路径数字误认为真实 UI 体验。四、一键复现两条命令得到整张基线基线文档指向 perf/README.md 的复现流程。在仓库根目录依次执行HOME_DIR$(mktemp -d /tmp/codeburn-perf-XXXX) node scripts/perf/gen-fixture.mjs --home $HOME_DIR --target-mb 30 node scripts/perf/run-metric.mjs --metric all --home $HOME_DIR也可以使用 package.json 中预置的 npm 脚本见 package.jsonnpm run perf:fixture -- --home $HOME_DIR --target-mb 30 npm run perf:all -- --home $HOME_DIR脚本对应关系perf:fixture→node scripts/perf/gen-fixture.mjsperf:metric→node scripts/perf/run-metric.mjsperf:all→node scripts/perf/run-metric.mjs --metric all运行完成后结果落在perf/results/harness-时间戳/目录gitignored包含summary.json本次运行的全部指标汇总基线文档引用的perf/results/harness-2026-08-29T18-12-01-675Z/summary.json即此产物timings.csv按 release-acceptance 的timings.csv模板输出的逐 trial 明细列头见 scripts/perf/lib.mjsrun_id、case_id、surface、persona、operation、trial、cache_state、start_monotonic_ms、first_feedback_ms、first_useful_ms、complete_ms、cpu_peak_pct、rss_peak_bytes、calls、tokens、cost_usd、identical_totals、notes每个指标各自的 JSON 文件session-parse.json、period-switch.json等内含machine快照SHA、分支、dirty 状态、OS/arch、Node 版本、CPU/内存、loadavg、CLI 入口等见 scripts/perf/lib.mjs。钉住新阶段基线的方式是手动的把一次运行的summary.json数字人工粘贴进perf/BASELINES.md。文档明确说明钉住每个阶段只发生一次不需要脚本。run-metric 支持的参数scripts/perf/run-metric.mjs 中定义了合法的--metric取值session-parse、incremental-reparse、period-switch、cold-start-cli、dock-tui-proxy、memory、all其余参数--home dir必填隔离 HOME 路径--output dir结果输出目录默认perf/results/run-id目录以 0o700 权限创建--trials-cold n冷 trial 次数默认 3--trials-warm n热 trial 次数默认 5--idle-ms nmemory 指标的空闲等待毫秒数默认 01h 泄漏检查传 3600000--help / -h打印用法。这与 release-acceptance 的标准三次冷、五次热、同一冻结语料的受控性能分布要求一致见 docs/release-acceptance/README.md 的 Timing and correctness 小节。五、合成语料确定性、可复现、防污染性能度量的前提是可控输入。scripts/perf/gen-fixture.mjs 生成30MB 级别的确定性合成会话语料其关键设计纯合成内容路径是假的/work/api-gateway、/work/billing、/work/web-app、/work/infra工具载荷是 lorem 文本。文档严禁把真实会话文件复制进仓库或 PR生成字节只存在于被 gitignore 的隔离 HOME 下。覆盖多 provider 格式既有 Claude 风格的type: user / type: assistantJSONL含usage字段、cache_read/cache_creation token也有 Codex 风格的session_meta / event_msg / response_item混合事件与累计 token_count见 scripts/perf/gen-fixture.mjs。时间分布92 天跨度day0 对齐 UTC 午夜保证 today/7D/30D 查询都有数据可查模型从claude-sonnet-4-5、claude-opus-4-8、claude-haiku-4-5中选取工具从Read/Edit/Bash/Glob/Grep中选取。可复现随机默认--seed0x9e3779b9驱动 mulberry 32 PRNG配合--target-mb可调节语料大小默认 30最小 1。清单标记生成结束时在 HOME 写入.codeburn-perf-fixture.json含 kind、seed、target_mb、bytes、files、sessions、span_days、day0、append_target 等run-metric 启动时若找不到该标记会直接报错提示先运行生成器见 scripts/perf/run-metric.mjs。防真实 HOME 写入assertIsolatedHome()见 scripts/perf/lib.mjs会对比解析后的目标路径与当前用户真实 HOME若目标在真实 HOME 之下则直接拒绝。这些设计在测试中也有验证tests/perf-harness-phase0.test.ts 断言了拒绝写入真实 HOME和生成带标记的隔离 fixture且包含混合事件类型、Claude 与 Codex 两种目录结构。六、环境隔离与升级路径同一套隔离语义性能数字只有隔离了外部变量才有意义。isolatedEnv()见 scripts/perf/lib.mjs与 scripts/upgrade-path/run.mjs 的cliEnv()保持一致隔离HOME/USERPROFILE/APPDATA/LOCALAPPDATA/CODEBURN_CACHE_DIR并额外固定TZ: UTC、XDG 三件套XDG_CONFIG_HOME、XDG_DATA_HOME、XDG_CACHE_HOME同时设置CODEBURN_PRICING_SNAPSHOT_ONLY: 1只用本地定价快照CODEBURN_FX_NO_FETCH: 1禁用网络抓取。这样所有 provider 都在隔离 HOME 下解析各自的默认目录Claude 读~/.claude/projectsCodex 读~/.codex/sessions宿主机上真实的或残留的数据不会进入对比。CLI 入口优先使用dist/cli.js否则回退到tsx src/cli.ts见 scripts/perf/lib.mjs——基线文档记录的 CLI 为tsx src/cli.ts。七、ServeClient 与等待路径测量机制period-switch、dock-tui-proxy、memory三个指标都通过serve --stdio长驻进程测量。ServeClient见 scripts/perf/lib.mjs实现了一套基于 JSON 行的 stdin/stdout 协议子进程 stdout 按行解析遇到{ready:true}帧即认为 serve 就绪记录serve ready时间请求以{id, args}写入 stdin响应按 id 匹配 waiterprogress帧会记录firstFeedbackMs首帧反馈时间最终帧记录completeMs请求超时默认 180 秒serve 30 秒内不发{ready:true}视为失败。由此可以区分first_feedback_ms与first_useful_ms两个观测点与 release-acceptance 的首可见反馈 / 首个有用输出 / 完整结果 / 热导航观测体系对齐。period-switch内部流程见 scripts/perf/run-metric.mjs依次是清缓存 → 启动 serve → 全量语料加载--period all→ 首个 7D → 首个 30D → 5 轮热 7D/30D并显式不设置CODEBURN_SERVE_PROGRESSIVE因为 18 秒的 7D 凭证是热应用 完整缓存而非降级的首帧渲染。memory指标则会在冷加载后读取进程 RSS若传了--idle-ms再等待后二次读取以检测泄漏。八、迭代契约性能改动如何进主分支perf/README.md 定义了严格的迭代契约任何性能改动都必须遵守一次只攻击基线表中的一个行从当前 main 开分支命名perf/metric-short-name只做一处改动用本测试平台测量提交 PR 时附上 before、after、命令、fixture永不从该分支直接 merge结果追加进 perf/ITERATION-LOG.md保留或回退。当前迭代日志只有一条记录Phase 0 harness 本身n/a → pinnedkept说明基线建立后尚无产品改动。同时测试平台被明确禁止触碰以下产品热路径文件这些表面有进行中或刚落地的质量工作对应 PR 1159–1171 及 #1149/#1062/#940src/parser.tssrc/session-cache.tssrc/dashboard.tsxapp/electron/main.tsapp/electron/cli.tsmac/Sources/CodeBurnMenubar/**也就是说性能改动不允许顺手修改解析器、缓存、仪表盘或 Electron/Menu Bar 入口——测试平台的边界由这个禁止清单划死。九、与 release-acceptance 的关系性能平台是 #1164 引入的 release-acceptance ledger 的延伸但并不取代它scripts/release-acceptance/run.mjs仍是 SHA/包校验关卡性能平台只是产出timings.csv模板形状的等待路径数字让不友好的评审者能用一条命令复跑文档明确docs/release-acceptance/README.md 中说明等待路径性能数字session parse、incremental re-parse、period switch、CLI cold start位于scripts/perf/与perf/README.md该测试平台产出timings.csv模板不取代 runner也不声称覆盖已安装 Desktop/Menu Bar UI。证据阶梯上源码检查/单元测试 → 冻结 fixture → 打包安装制品 → 真实交互 → 受影响机器证明性能平台属于冻结 fixture级别真实 UI 交互first_feedback、hover、view-switch、TTY 按键仍由 computer-use 级别的人工审计RA-PERF-003/005/006负责。十、读表时的三条纪律wait-path ≠ 已安装 UI表头自述These rows are wait-path measurements through isolated HOME CLI/serve. They are not installed Desktop/Menu Bar UI proof.凡标注UI NOT VERIFIED / NOT VERIFIED的行都不要当作真实用户体验数字引用。历史凭证 ≠ 本仓库可推导18286.98ms 与 250ms 目标来自未公开的已安装应用审计只能作为上下文不能用本 fixture 重新推导。对比必须同语料同机器复现时机器快照会记录 SHA/Node/OS 等见machineSnapshot跨机器、跨语料、跨 SHA 的数字不可直接比较。这套一条命令一个指标、基线钉住、前后数字必须有的方法论正是 CodeBurn 把 18 秒概览压缩到毫秒级响应、并让每次性能改进都可审计、可复现、可回滚的基础设施。赞分享【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载相关推荐终极武器SharpShooter红队必备的Payload生成框架完全指南终极武器SharpShooter红队必备的Payload生成框架完全指南 SharpShooter是一款专为红队行动设计的Payload生成框架能够检索和执FastAPI 基准测试Benchmarks深度解读如何正确看待性能对比与框架分层FastAPI 基准测试Benchmarks深度解读如何正确看待性能对比与框架分层 独立第三方 TechEmpower 基准测试显示运行在 Uvicor后端Web框架API设计路径规划算法性能大比拼gh_mirrors/pa/PathPlanning 深度基准测试指南路径规划算法性能大比拼gh_mirrors/pa/PathPlanning 深度基准测试指南 路径规划算法在现代机器人导航、自动驾驶和游戏AI中扮演着关键角色示例工程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考