Measure how long GitHub Actions jobs and steps took across past runs, and find the pull request that made CI slower. Use for any question about CI duration, a slow job, or when CI got slow.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Measure Wado's performance or the size of the Wasm it generates, and refresh the benchmark/ and wasm-size/ README files. Use for any benchmarking or size-measurement request, whichever benchmark it names.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
실행 점수 미검증
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
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 and javac, which
benchmark/mise.toml provides; 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, each to its own log in
scratchpad/, then pick per row with
node benchmark/pick.ts scratchpad/run{1,2,3}.log (throttling
only ever slows things down). Use that tool rather than reading the logs by
eye: it keys rows by (task, implementation, phase) and selects on ms/iter, so
a rate that rounds to a tie across runs cannot pair with the wrong ms/iter.
Which benchmarks run, and in what order, is benchmark/mise.toml's all
task.oha + pinned cores):
SLICE=10 ROUNDS=3 SHAPES="1 4" mise run benchmark-http-routing. It keeps
the per-(server, request) max internally, so one invocation suffices, and it
measures one worker shape per entry in SHAPES. Add HEADROOM_CHECK=1 when
CONNECTIONS_PER_WORKER, OHA_CORE_COUNT or SHAPES changed, to confirm
oha was not the ceiling.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.WADO_BENCH_FLAGS is appended to every wado compile / wado run the harness
issues, so an arm costs a benchmark run rather than a release rebuild:
set -e # a failed arm would leave pick.ts choosing among the rest
for t in 13 20 32; do
WADO_BENCH_FLAGS="--optimize-inline-threshold $t" mise run benchmark-all > scratchpad/thr$t.log 2>&1
done
node benchmark/pick.ts scratchpad/thr{13,20,32}.log
Read the sweep with pick.ts the same way as a best-of-three: it keys rows by
(task, implementation, phase), so the "best" column names the winning arm per
row. Only a knob both wado compile and wado run accept can be swept this
way, since the harness passes the flags to both. The knob a sweep settles on is
a default in optimize.rs, not a flag the README's numbers were taken under —
re-run the suite unflagged before updating the tables.
Comparing the settled default against origin/main is a different measurement,
and WADO_BIN plus ab.ts is how: see the wado-performance skill.
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. The unit is the benchmark's own
(numbers/s, px/s, conversions/s, MB/s, req/s); vs best = fastest rate / this
rate.
Report a change between two measurements with improvement as positive: +9%
means faster, -13% slower. This is the sign ab.ts prints.
Each benchmark prints the implementations it compared, so read them off the run
rather than from a list here. Two are conditional: the ANTLR4 rows for
sqlite-parse and gale-gen are skipped when java is absent, and the run
says SKIP: when it drops one.
Benchmarks auto-calibrate their iteration count to run ~1s, so no manual denomination is needed. A workload whose single iteration approaches that reports one iteration and stops averaging — shrink its problem size, across every language implementation of that benchmark, until it calibrates again.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Measure how long GitHub Actions jobs and steps took across past runs, and find the pull request that made CI slower. Use for any question about CI duration, a slow job, or when CI got slow.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
How to answer code review feedback — a human reviewer, CodeRabbit, or any review bot. Verify the findings, report the classes they are instances of to the user before fixing, then fix the class rather than the sites named. Put design decisions to the user, then run /distill. Invoke when responding to review comments on a pull request, or to the findings of a /code-review run.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Investigate and improve code coverage for the wado-compiler crate. Use for any question about what the tests do and do not reach, dead code included.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Review the branch with /code-review at high, then answer the findings with /code-review-response.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use rust-gdb to inspect variables and step through code without modifying it. Prefer it over print debugging for any investigation into what the compiler is actually doing (lldb is unavailable on Claude Code Web).
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Cut the branch down to what the code cannot say: reuse what exists, remove duplication, dead code, and wasted work, turn invariants into asserts, and delete the comments the code already speaks. Run it after answering review feedback too — a fix written to satisfy a reviewer is the least distilled code on the branch.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.