Agent skill · zed-industries
gpui-bench
Design, write, review, run, and interpret production-shaped GPUI Criterion benchmarks, including gpui::bench, BenchAppContext, renderer and task benchmarks, headless Metal frame data, responsiveness and hang regressions, feature isolation from test-support, and before/after performance evidence.
What it needs
About 11k tokens when loaded.
What this skill does
GPUI Benchmarks Use this skill when a user asks to benchmark GPUI code, reproduce a UI hang or frame drop, evaluate a performance fix, use #[gpui::bench], interpret BenchReport, or review whether a GPUI benchmark represents production. The primary goal is UI responsiveness. Throughput matters, but a UI that finishes work quickly while blocking input and frames is still regressed. Start with the performance question Before editing, establish or derive: 1. What user-visible problem is being reproduced: slow computation, long foreground poll, delayed input, frame drops, scrolling hitch, GPU draw cost, or a true hang? 2. What production event starts the work, and what path performs it? 3. What competing UI work must remain responsive? Prefer a rendered progress indicator, cursor, spinner, or scrolling frame when practical. 4. What target frame rate applies? GPUI defaults to 120 FPS, an 8.33 ms frame budget. At 60 FPS the budget is 16.67 ms. 5. What fixed workload sizes expose a progression from normal to degraded to severe? 6. What state proves the workload completed without dropping, duplicating, or reordering work? 7. Which commits are the baseline and candidate, and can the exact same benchmark code run on both? Ask only for inputs that cannot be derived from the repository, issue, trace, or existing benchmark. Non-negotiable rules A benchmark must not enable any crate's test-support feature, directly or transitively. Use production constructors, storage, executors, rendering, synchronization, and data sizes whenever practical. Do not use TestAppContext, deterministic test executors, reduced test-only CRDT settings, fake clocks, fake filesystems, or fake services merely because setup is easier. A narrow benchmark seam may simulate an external boundary such as a PTY, server, or filesystem event, but everything after that boundary should follow the production path. A performance fix should normally include or extend a benchmark that reproduces its problem. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills zed-industries/gpui-bench