Deno 基准测试体系：deno_bench 基准套件的运行、过滤与结果产出全解析

Deno 基准测试体系deno_bench 基准套件的运行、过滤与结果产出全解析【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno本文围绕 Deno 仓库 tests/bench/README.md 所讲的两个核心点——如何用cargo bench --bench deno_bench -- 名称对基准测试进行过滤运行以及基准结果如何被产出与可视化——展开并结合 tests/bench/main.rs 的完整实现说明各指标执行时间、内存峰值、二进制体积、系统调用数等的采集方式与结果 JSON 的聚合流程。读完后你可以独立跑通 Deno 的官方基准套件、理解每个过滤参数对应哪一组测量并知道target/bench.json中各字段的真实来源。1. 基准套件入口deno_bench目标与过滤命令tests/bench/README.md 给出的第一条实战命令就是基准过滤的入口cargo bench --bench deno_bench -- bundle其中--之后的参数README 中示例为bundle是基准名称过滤器。这个deno_bench基准目标在 tests/bench/Cargo.toml 中声明[package] name bench_tests autobenches false [[bench]] name deno_bench harness false path main.rs [[bench]] name lsp_bench_standalone harness false path lsp_bench_standalone.rs几个关键点harness false表示该目标不依赖 libtest 默认测试框架main.rs是完全自托管的执行器该包被列入了根 Cargo.toml 的 workspace 成员tests/bench、tests/bench_util且根工作区以deno_bench_util { version 0.252.0, path ./tests/bench_util }的形式导出了基准工具库除deno_bench外还有一个独立的lsp_bench_standalone目标专门用于 LSP 基准的独立运行。tests/bench/main.rs#L363-L384 中的过滤逻辑与 README 的命令一一对应程序启动时读取第一个位置参数若它是某个基准名则benchmarks.retain(|s| s filter)只保留该组程序同时要求命令行中出现--bench开关cargo 在基准模式下传给自定义 harness 的约定参数否则直接退出避免误当作普通二进制执行。需要说明的一点是README 中的bundle是历史基准名对应早期对deno bundle子命令的计时。从当前源码的基准清单看现存的过滤值已变为下面第 2 节列出的六组README 示例更多是演示“如何传过滤参数”这一机制本身。2. 可用的过滤参数六组基准tests/bench/main.rs#L363-L370 中定义了当前支持的基准组清单过滤参数测量对象实现位置exec_time典型命令deno run等的执行耗时分布main.rs#L151-L218binary_sizedeno 可执行文件、swc/v8 rlib、快照文件体积main.rs#L247-L293cargo_depsCargo.lock中的依赖包总数main.rs#L321-L334lspLSP 请求回放补全、悬停、编辑耗时lsp.rsstrace系统调用总数、线程数仅 Linuxmain.rs#L432-L476mem_usage峰值内存time -v采样main.rs#L295-L319例如只跑 LSP 一组cargo bench --bench deno_bench -- lsp不带过滤参数则六组全部执行。3. exec_timehyperfine 驱动的执行时间基准这是套件中最核心的一组。tests/bench/main.rs#L34-L147 以EXEC_TIME_BENCHMARKS常量表声明了全部被测命令每一项是(名称, deno 参数, 期望退出码)三元组覆盖的场景包括冷启动cold_hello、cold_relative_import带--reload强制重新加载模块图以及对应热路径的hello、relative_import错误路径error_001并断言进程退出码为 1Worker 相关workers_startup、workers_round_robin、workers_large_message内置功能热点text_decoder、text_encoder、text_encoder_into、response_string。执行细节main.rs#L151-L218使用预编译好的hyperfine工具test_util::prebuilt_tool_path(hyperfine)一次性跑完所有命令参数为--export-json hyperfine_results.json --warmup 3即每组命令 3 次预热源码注释明确要求cold_*用例必须排在热用例之前——因为冷启动基准顺带完成了模块缓存的填充先执行才能保证后续热用例读到的缓存状态正确对error_001这类带期望退出码的用例命令尾部会追加; test $? -eq 1的 shell 断言防止“命令跑挂了但耗时很短”污染数据从 hyperfine 的 JSON 输出中只保留RESULT_KEYS [mean, stddev, user, system, min, max]六个统计量按基准名归入结果字典。4. mem_usage、strace、binary_size 与 cargo_deps内存峰值mem_usagerun_max_mem_benchmark 对每个EXEC_TIME_BENCHMARKS用例执行time -v deno args解析 stderr 中的最大驻留内存。这意味着该组指标依赖 Linux 的time命令非 Linux 环境需自行保证可用。系统调用与线程数strace仅在cfg!(target_os linux)下启用。以strace -c -f -o 临时文件包裹每条被测命令并强制LC_NUMERICC保证数字格式可解析线程数取clone/clone3调用数加 1系统调用总数取totalmain.rs#L432-L476。二进制体积binary_sizeget_binary_sizes 汇总四类体积——deno 可执行文件本身、target/release/deps下所有libswc*与libv8*rlib 的累计大小以及三个编译期快照文件CLI_SNAPSHOT.bin、RUNTIME_SNAPSHOT.bin、COMPILER_SNAPSHOT.bin。由于 cargo 的OUT_DIR不可预测快照文件通过walkdir全树搜索取得且同名文件以 mtime 最新者为准。依赖数量cargo_deps统计根目录 Cargo.lock 中[[package]]段的行数作为依赖膨胀的长期趋势指标并带count 10的健全性断言main.rs#L321-L334。5. LSP 基准真实请求回放LSP 基准由 tests/bench/lsp.rs 实现思路是“录制回放”用include_bytes!把录制的 JSON-RPC 请求序列如testdata/db_messages.json、testdata/deco_apps_requests.json编译进二进制运行时通过tower-lsp的LspClientBuilder启动deno lsp回放悬停、补全、高亮、代码编辑等请求并计时例如 bench_deco_apps_edits 会回放一个完整应用仓库的编辑请求流。结果以lsp_exec_time计入总输出。该模块同时可经由独立目标lsp_bench_standalonetests/bench/lsp_bench_standalone.rs单独执行。6. 同目录下的 JS 侧基准脚本tests/bench/目录下还有一批使用Deno.benchAPI 编写的 JavaScript 基准用于测量 JS 侧热点例如tests/bench/deno_common.jsDate.now()、performance.now()注释标注为“非常轻量的 op理应高度可优化”、new URL(...)解析、atob/btoaBase64 往返、open_file_sync、从/dev/zero读字节等多数用例显式指定迭代次数如{ n: 5e5 }tests/bench/command.js以Deno.Command启动外部进程echo、cat 128kb的开销基准其余streams.js、tcp.js、sqlite.js、webstorage.js、url_parse.js等文件则覆盖对应运行时 API。这些脚本与main.rs的进程级基准互补前者测量 Deno API 的函数级吞吐后者测量整条 CLI 链路的端到端表现。7. 结果产出target/bench.json与数据管道所有指标最终汇聚为 main.rs#L337-L357 中的BenchResult结构并序列化为 JSON字段与来源的对应关系如下字段来源created_at/sha1当前 UTC 时间戳与git rev-parse HEAD用于按提交对齐历史数据benchmarkexec_time 的六项统计量源码 TODO 注释说明其历史名称应为exec_timebinary_size第 4 节的四类体积cargo_deps依赖包数量lsp_exec_timeLSP 请求回放耗时max_memorytime -v解析的峰值内存syscall_count/thread_countstrace 统计该 JSON 被写入target/bench.jsonmain.rs#L483-L486。后续的聚合由 tools/build_benchmark_jsons.js 完成它以构建目录下的bench.json为输入为基准数据仓库生成按基准维度拆分的 JSON 序列。README 中“benchmark plots”一节即指向这一数据管道的下游——基准趋势图由外部托管的仪表盘渲染README 给出的两个地址为外部站点本文按规范不输出该链接。源码中的 TODO 注释也表明历史上数据曾提交至独立的 benchmark_data 仓库该流程已标记为弃用。8. 实践要点与前提条件结合源码实际跑这套基准时值得注意指定被测二进制main()优先读取环境变量DENO_BENCH_EXE缺省使用test_util::deno_exe_path()即本树构建出的 deno 可执行文件main.rs#L388-L393因此测量的是当前工作区代码而非安装的发布版执行目录程序会set_current_dir到仓库根用例中出现的tests/testdata/...相对路径依赖这一点过滤语义--后参数等于--bench被视为模式开关而非过滤器传入未知名称会使基准列表清空但仍会走完整流程写出空结果建议过滤前先对照第 2 节的清单平台差异strace组仅在 Linux 生效mem_usage依赖 GNUtimehyperfine通过test_util的预构建工具路径获取需构建流程已准备好该工具结果解读exec_time 采用mean/stddev/user/system/min/max六元组跨提交对比时建议以mean为主、stddev为噪声参考sha1字段可用于把一次运行精确对齐到源码提交。9. 小结tests/bench/README.md 虽然简短但点出了 Deno 基准体系的两条主线cargo bench --bench deno_bench -- 组名的过滤式运行以及结果向外部基准图谱的持续上报。深入源码后可以确认这套体系由 tests/bench/Cargo.toml 声明的deno_bench/lsp_bench_standalone目标驱动tests/bench/main.rs 以 hyperfine、strace、time -v等系统工具组合出执行时间、内存、系统调用、二进制体积、依赖数五类进程级指标tests/bench/lsp.rs 提供 LSP 请求回放同目录的Deno.bench脚本补充 JS 侧函数级基准最终所有指标连同提交号写入target/bench.json经 tools/build_benchmark_jsons.js 拆分为时序数据供趋势分析使用。理解这条从“过滤命令”到“趋势图”的完整链路是复现和解读 Deno 官方性能数据的起点。【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考