rspack-perf-valgrind-goal

Optimizes Rspack benchmark stages against percentage targets using local Docker and Valgrind Callgrind measurements.

12.9k|843|Updated Apr 1, 2022
One-click install
npx skills add https://github.com/web-infra-dev/rspack --skill rspack-perf-valgrind-goal
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rspack-perf-valgrind-goal
Source: https://github.com/web-infra-dev/rspack/tree/main/.agents/skills/rspack-perf-valgrind-goal
Command: npx skills add https://github.com/web-infra-dev/rspack --skill rspack-perf-valgrind-goal

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

Rspack performance work often relies on cloud CI benchmarks like CodSpeed or GitHub Actions, which are noisy, slow to iterate on, and hard to reproduce locally. This Skill provides a fully local, reproducible measurement loop that judges optimization success purely by Callgrind instruction counts from a pinned Docker environment.

Core Features & Use Cases

  • Reproducible local measurement: Builds a pinned Rust toolchain Docker image and runs Rspack benchmark binaries under Valgrind Callgrind, producing exact instruction counts per benchmark stage.
  • Autonomous optimization rounds: Runs structured rounds of code change, correctness validation, independent review, committed snapshots, measurement, and retain-or-revert decisions until a user-specified percentage target is met.
  • Progress reporting: Maintains a single persistent PR comment or task report tracking base values, per-round deltas, decisions, and correctness results.
  • Use Case: A maintainer is asked to reduce the instruction count of a specific Rspack compilation stage by 5%. The Skill measures an immutable base, iterates scoped optimizations, validates correctness, and reports each round until the target is confirmed locally.

Quick Start

Use the rspack-perf-valgrind-goal skill to optimize the specified Rspack benchmark stage by the requested percentage using local Docker and Valgrind measurements.

Frequently Asked Questions about rspack-perf-valgrind-goal

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I measure Rspack benchmark performance locally with Valgrind?

Use the run_local_valgrind.sh helper to build a pinned Docker image, prepare fixtures once with pnpm bench:prepare, then run the measure command with the benchmark target, exact filter, and output directory. It executes the benchmark binary under Callgrind and writes instruction counts to run-*.instructions files.

How do I optimize a Rspack benchmark stage to hit a percentage target?

Provide the exact benchmark filter, threshold, and scope, then follow the per-round loop: make a scoped change, validate correctness, review the diff, commit, measure locally under Valgrind, and retain or revert based on the instruction count delta. Repeat until the target is met or the round limit is reached.

Does this workflow use CodSpeed or GitHub Actions results?

No. All performance decisions come exclusively from local Callgrind instruction counts in a pinned Docker environment. The --cfg codspeed flag is only a compile-time source switch exposing Valgrind client-request boundaries; no CodSpeed service, token, upload, or CI status participates.

Can I compare Valgrind instruction counts across different machines?

No. Comparisons are only valid within the same native Docker platform, image ID, fixture directory, benchmark target, filter, and environment. Absolute instruction counts differ between linux/arm64 and linux/amd64, so base and candidate must be measured on identical frozen inputs.

Why does the Rspack benchmark build get killed in Docker on macOS?

The optimized benchmark build can receive SIGKILL with Docker Desktop's default 8 GiB memory allocation. Increase Docker Desktop memory to about 16 GiB, restart the engine, and resume; cached build volumes are preserved.

What happens when an optimization round does not improve performance?

A neutral or slower round is reverted with a new follow-up commit rather than amending history. Correctness-only fixes may be retained even if performance is neutral, and their measured value becomes the comparison point for the next round.