performance-investigation

AI Community

Repo stars 86,684
Author repo svelte

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Investigate performance regressions and find opportunities for optimization pnpm bench:compare main foo If you pass one branch…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Quick start”, “Where outputs go”, “Suggested investigation flow”, “Fast benchmark loops”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name performance-investigation directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Quick start / Where outputs go / Suggested investigation flow” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Quick start

Start from a branch you want to measure (for example foo).
Run:

pnpm bench:compare main foo

If you pass one branch, bench:compare automatically compares it to main.

Where outputs go

Summary report: benchmarking/compare/.results/report.txt
Raw benchmark numbers:
- benchmarking/compare/.results/main.json
- benchmarking/compare/.results/<your-branch>.json
CPU profiles (per benchmark, per branch):
- benchmarking/compare/.profiles/main/*.cpuprofile
- benchmarking/compare/.profiles/main/*.md
- benchmarking/compare/.profiles/<your-branch>/*.cpuprofile
- benchmarking/compare/.profiles/<your-branch>/*.md

The .md files are generated summaries of the CPU profile and are usually the fastest way to inspect hotspots.

Suggested investigation flow

Open benchmarking/compare/.results/report.txt and identify largest regressions first.
For each high-delta benchmark, compare:
- benchmarking/compare/.profiles/main/<benchmark>.md
- benchmarking/compare/.profiles/<branch>/<benchmark>.md
Look for changes in self/inclusive hotspot share in runtime internals (runtime.js, reactivity/batch.js, reactivity/deriveds.js, reactivity/sources.js).
Make one optimization change at a time, then re-run targeted benches before re-running full compare.

Fast benchmark loops

Run only selected reactivity benchmarks by substring:

pnpm bench kairo_mux kairo_deep kairo_broad kairo_triangle
pnpm bench repeated_deps sbench_create_signals mol_owned

Tests to run after perf changes

Runtime reactivity regressions are most likely in runes runtime tests:

pnpm test runtime-runes

Helpful script

For quick cpuprofile hotspot deltas between two branches:

node benchmarking/compare/profile-diff.mjs kairo_mux_owned main foo

This prints top function sample-share deltas for the selected benchmark.

Practical gotchas

bench:compare checks out branches while running. Avoid uncommitted changes (or stash them) so branch switching is safe.
Each bench:compare run rewrites benchmarking/compare/.results and benchmarking/compare/.profiles.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @sveltejs · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: macOS · Linux · Windows
Runtime requirements: Node.js
Detected file/system behavior: Read-only
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview performance-investigation.preview

# Where outputs go

- Summary report: `benchmarking/compare/.results/report.txt`
- Raw benchmark numbers:
  - `benchmarking/compare/.results/main.json`
  - `benchmarking/compare/.results/<your-branch>.json`
- CPU profiles (per benchmark, per branch):
  - `benchmarking/compare/.profiles/main/*.cpuprofile`

SKILL.md SKILL.md

## Quick start

1. Start from a branch you want to measure (for example `foo`).
2. Run:

```sh
pnpm bench:compare main foo
```

If you pass one branch, `bench:compare` automatically compares it to `main`.

## Where outputs go

- Summary report: `benchmarking/compare/.results/report.txt`
- Raw benchmark numbers:
  - `benchmarking/compare/.results/main.json`
  - `benchmarking/compare/.results/<your-branch>.json`
- CPU profiles (per benchmark, per branch):
  - `benchmarking/compare/.profiles/main/*.cpuprofile`
  - `benchmarking/compare/.profiles/main/*.md`
  - `benchmarking/compare/.profiles/<your-branch>/*.cpuprofile`
  - `benchmarking/compare/.profiles/<your-branch>/*.md`

The `.md` files are generated summaries of the CPU profile and are usually the fastest way to inspect hotspots.

## Suggested investigation flow

1. Open `benchmarking/compare/.results/report.txt` and identify largest regressions first.
2. For each high-delta benchmark, compare:
   - `benchmarking/compare/.profiles/main/<benchmark>.md`
   - `benchmarking/compare/.profiles/<branch>/<benchmark>.md`
3. Look for changes in self/inclusive hotspot share in runtime internals (`runtime.js`, `reactivity/batch.js`, `reactivity/deriveds.js`, `reactivity/sources.js`).
4. Make one optimization change at a time, then re-run targeted benches before re-running full compare.

## Fast benchmark loops

Run only selected reactivity benchmarks by substring:

```sh
pnpm bench kairo_mux kairo_deep kairo_broad kairo_triangle
pnpm bench repeated_deps sbench_create_signals mol_owned
```

## Tests to run after perf changes

Runtime reactivity regressions are most likely in runes runtime tests:

```sh
pnpm test runtime-runes
```

## Helpful script

For quick cpuprofile hotspot deltas between two branches:

```sh

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Quick start → Where outputs go → Suggested investigation flow → Fast benchmark loops → Tests to run after perf changes → Helpful script
terms    -> 1. Start from a branch you want to measure (for example foo). · If you pass one branch, bench:compare automatically compares it to main. · The .md files are generated summaries of the CPU profile and are usually the fastest way to inspect hotspots. · 1. Open benchmarking/compare/.results/report.txt and identify largest regressions first. · This prints top function sample-share deltas for the selected benchmark. · - bench:compare checks out branches while running.
files/cmd -> foo · bench:compare · main · benchmarking/compare/.results/report.txt · benchmarking/compare/.results/main.json · benchmarking/compare/.results/<your-branch>.json · benchmarking/compare/.profiles/main/.cpuprofile · benchmarking/compare/.profiles/main/.md
body sha256 -> 898549e48cd3