← ClaudeAtlas

load-testslisted

Run the VibeTags benchmark harness in load-tests/ and report the numbers honestly — annotation-volume and memory sweeps, JMH hot-path and cache-hit microbenchmarks, the processor-tax control — then record a release baseline under load-tests/results/. Use when the user says "load tests", "benchmarks", "capture a baseline", "did this get slower", "JMH", "performance regression", or before cutting a VibeTags release.
PIsberg/vibetags · ★ 15 · Testing & QA · score 77
Install: claude install-skill PIsberg/vibetags
# Load tests The harness lives in `load-tests/`. It is a standalone Maven project that compiles synthetic annotated sources with and without the processor and subtracts. `load-tests/README.md` documents the harness; `load-tests/results/README.md` documents the baselines. This skill is the judgement around both: which run answers which question, and which of the resulting numbers may be quoted. The single most important fact about this harness: **most of what it prints is noise on a developer workstation.** Two runs of an identical build have differed by up to 1.93x on the JMH hot path. Only the allocation numbers are stable enough to make claims from. Everything below follows from that. ## Step 1 — Decide which question is being asked **"Does this change make the processor slower?"** Only the allocation sweep can answer that on an ordinary machine, and only if both versions are measured back-to-back in one sitting. See Step 4. **"Capture a baseline for the release."** The full capture in Step 3, recorded under `load-tests/results/<version>/` with an `env.txt` that says what the machine was doing. **"Prove this specific optimisation works."** Neither sweep will show it unless it is large. Write a targeted JMH benchmark or a targeted stress test instead — `WriteCacheHitBenchmark` and `SignatureCaptureStressTest` are the two worked examples in the repo, and both exist because the general sweeps could not see the effect they were built to measure. ## Step 2 — Install the v