菜单
Run Wado performance benchmarks (count-prime, mandelbrot, zlib, json, http-routing, …) and wasm-size reports, then update the benchmark/ and wasm-size/ README files. Use when asked to benchmark Wado, measure performance, or refresh the benchmark/wasm-size results.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Analyze and improve the runtime speed of a Wado program's compiled guest Wasm — profile hot functions, read the generated WIR for allocations and copies, reason about the WasmGC cost model, and A/B-measure a fix. Use for guest-side speed work (serde, parsers, numeric loops, hot stdlib). For host-side native compiler profiling see profiling-wado-compiler; for wrong-code in an optimizer pass see optimizer-debug.
Project rules for opening a PR: a Conventional Commits title, and a description scoped to origin/main...HEAD (three-dot) with no trial-and-error history and no test section. Read before creating or editing any pull request.
Profile the native Rust `wado` binary (compile/serve/run) with a sampling profiler to find host-side bottlenecks. Use for native CPU profiling, not guest wasm (see wado-performance for that).
Transpile Wado Wasm components to JS with jco and run/benchmark them on Node. Use when running Wado on Node or browsers via jco, debugging jco-transpiled runtime failures, or benchmarking Wado on Node.
Mandatory task-completion flow: self-review the branch, update docs (spec/cheatsheet/compiler/optimizer), then run `mise run on-task-done` (build, clippy-fix, golden + format fixtures, doc-stdlib, format, tests; 40+ min) and commit its generated changes. Run before committing a finished task or opening a PR.
Workspace-specific Rust rules that override common habits: panic instead of dummy or no-op fallbacks, no wildcard match arms, dependencies managed in the workspace Cargo.toml, 2024 edition, zero warnings and clippy lints. Read before writing or editing Rust (.rs) code.
| name | benchmark |
| description | Run Wado performance benchmarks (count-prime, mandelbrot, zlib, json, http-routing, …) and wasm-size reports, then update the benchmark/ and wasm-size/ README files. Use when asked to benchmark Wado, measure performance, or refresh the benchmark/wasm-size results. |
Run the benchmarks and update benchmark/README.md (and wasm-size/README.md).
mise run on-task-started
vendor/wasmtime submodule must exist (the SessionStart hook handles it;
otherwise git submodule update --init --recommend-shallow vendor/wasmtime).oha (cargo install oha); bun is mise-managed.java (sqlite-parse also
needs javac); the jar is fetched to ~/.cache/gale. Those rows are skipped
if the tool is absent.rustup target add wasm32-wasip1 and Moonbit
(curl -fsSL https://cli.moonbitlang.com/install/unix.sh | bash, then
moon update in each wasm-size/* dir).mise run benchmark-all three times; per implementation keep the
fastest value (throttling only ever slows things down). It runs 11
benchmarks serially: count-prime, mandelbrot, sieve, zlib, fts,
json-{twitter,canada,catalog}, sqlite-parse, syntax-highlight, gale-gen.oha + pinned cores):
SLICE=4 ROUNDS=5 CONNECTIONS=50 mise run benchmark-http-routing. It keeps
the per-(server, request) max internally, so one invocation suffices.mise exec -- node --version,
mise exec -- bun --version, rustc --version, cc --version | head -1
(wasmtime version is the vendored vendor/wasmtime workspace version).mise run report-wasm-size, then update
wasm-size/README.md.Each program prints a throughput line — <rate> <unit>/s (<ms> ms/iter, <n> iter) — per phase (zlib prints two phases, Compress:/Decompress:).
Read the rate and the ms/iter straight off; the iteration count auto-calibrates
to ~1s, so there is no total to report. Units: numbers/s (count-prime, sieve),
px/s (mandelbrot), conversions/s (fts), MB/s (zlib, json-*, sqlite-parse,
syntax-highlight, gale-gen), req/s (http-routing). vs best = fastest rate /
this rate. Implementations per benchmark:
java/javac; generated from
the same SQLite.g4; skipped if absent), Wado.g4 (needs java; the ANTLR4
row is skipped if java is absent)Benchmarks auto-calibrate their iteration count to run ~1s, so no manual denomination is needed. Keep each single iteration well under 1s: count-prime (limit) and fts (conversion count) are sized so one run is ~100ms, giving ~10 calibrated iterations. If a workload's one-shot cost exceeds ~1s it will report a single iteration — shrink its problem size across every language implementation of that benchmark to fix it.