live-perf

Measures and improves VS Code extension performance through live baselines and verified fix loops.

9.9k|1.8k|Updated Aug 8, 2016
One-click install
npx skills add https://github.com/gitkraken/vscode-gitlens --skill live-perf
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: live-perf
Source: https://github.com/gitkraken/vscode-gitlens/tree/main/.claude/skills/live-perf
Command: npx skills add https://github.com/gitkraken/vscode-gitlens --skill live-perf

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Performance tuning often relies on guesswork, leading to speculative optimizations that waste effort or introduce bugs. This Skill enforces a measure-first discipline: capture baselines in the running extension, classify findings by evidence tier, dispatch fixes only for measured regressions or convention violations, and re-measure to confirm real improvement.

Core Features & Use Cases

  • Live measurement across four categories: render/webview timing (Lit updateComplete, PerformanceObserver), RPC notification counts and payload sizes, hot-path code audits (missing @memoize, serialized awaits), and git call frequency analysis.
  • Three-tier finding discipline: Measured findings require baseline and post-fix numbers, Convention findings fix known GitLens patterns, and Speculation items are filed as open questions and never dispatched to agents.
  • Convergence loop with verification: fix agents must re-measure after changes, every agent diff is reviewed, and teardown/relaunch prevents stale-state contamination between baseline and post-fix runs.
  • Use Case: A developer notices the Commit Graph feels slow after a branch switch. The skill launches VS Code via the vscode-inspector MCP, captures 5-run averages of hydration time, RPC notifications, and git calls, identifies a missing @memoize on a hot getter, dispatches a fix agent, and confirms the improvement with fresh measurements.

Quick Start

Ask the assistant to run /live-perf on a specific feature, lifecycle stage, or branch diff, for example: measure and improve the performance of the Home webview hydration in the running extension.

Frequently Asked Questions about live-perf

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

FAQPage Schema
How do I measure VS Code extension performance at runtime?

Use the vscode-inspector MCP to drive the running extension and capture metrics with performance.now(), PerformanceObserver, and Lit updateComplete timings via evaluate_in_webview. Capture 3-5 runs per measurement and record averages in a baseline file before making any changes.

How to find performance regressions in a GitLens feature?

Run the live-perf skill against the feature scope: capture baselines for render time, RPC notification counts, and git calls, then compare against thresholds or a prior baseline. Findings above threshold dispatch fix agents that must re-measure to confirm improvement.

When should I use live-perf vs live-exercise?

Use live-exercise for functional, intent, and polish audits of a feature. Use live-perf standalone for perf-tuning an existing working feature, or let live-exercise Phase 7 delegate to it. Fix functionality first; perf-tune what already works.

Can I optimize code without measuring it first?

No. The skill forbids dispatching fixes for speculative optimizations. Only Measured findings with captured baselines and Convention violations like missing @memoize on hot paths get fix agents; everything else is filed in open-questions.md for user review.

Why must I teardown and relaunch between performance measurements?

Cached state from a prior run contaminates post-fix measurements, making improvements appear or disappear falsely. Cold-launch and startup metrics always require teardown plus relaunch, and any code change requires a fresh build and relaunch before the post-fix number counts.

What are the performance thresholds for webview hydration and git calls?

General guidance: webview hydration under 150ms, webview refresh under 100ms, more than 3 git calls per user action is suspicious, and more than 5 RPC notifications per action is suspicious. Thresholds are heuristics; above-threshold plus user-observable impact defines a real issue.