ExtSherlock — Extension Doctor

Diagnoses slow, conflicting, and resource-hungry VS Code extensions, and tells you exactly what to disable and why — from a dashboard in the Activity Bar.

What it does

• Live vitals — a small ECG-style strip that tracks the extension host's CPU %, heap, and event-loop lag (the truest proxy for "does the editor feel laggy right now"), sampled every couple of seconds with near-zero overhead.
• Deep Scan — on demand (or automatically when a lag spike is detected), runs a real V8 CPU sampling profile + heap allocation profile across the extension host for a few seconds, then attributes every sample back to the extension whose installed folder the code came from. This produces an actual per-extension CPU% / memory-allocation breakdown, not a guess.
• Conflict detection — flags when 2+ active extensions overlap in the same role (formatter, linter, git UI, icon theme, language server, spell checker), which is a common, hard-to-notice source of duplicate work.
• Context-aware suggestions — if a heavy extension only activates for a language you're not currently editing, it's flagged as a candidate to disable for this workspace.
• One-click fixes — every suggestion has a "Disable in this workspace" button that calls VS Code's own disable command, with a confirmation and a reload prompt.

How the attribution actually works (read this before trusting the numbers)

All extensions run inside one shared Node.js process (the "extension host"). There's no public VS Code API that hands you clean per-extension CPU/RAM — so ExtSherlock uses Node's built-in inspector module to run the same kind of CPU/heap sampling profile that VS Code's own Developer: Start Extension Host Profile command uses internally, then matches each sampled call frame's source file path against each installed extension's folder to attribute time and allocations. This is real measurement, not a heuristic — but it's necessarily a sample, not a perfect accounting: very short scans or very bursty extensions can be under- or over-represented. Longer Deep Scans (extsherlock.deepScanDurationMs) are more accurate at the cost of runtime.

Memory is reported as allocation volume observed during the scan window (via V8's sampling heap profiler), not "current resident memory owned by extension X" — the extension host's heap is shared and VS Code doesn't expose true per-extension retained memory. Treat it as a relative signal ("this one allocates a lot"), not an absolute RAM figure.

Project layout

src/
  extension.ts        entry point — wires monitoring, scanning, commands
  hostMonitor.ts       lightweight always-on CPU/heap/event-loop sampling
  eventLoopMonitor.ts  measures event-loop lag (the "does it feel slow" signal)
  profiler.ts           inspector-based CPU + heap sampling profile, per-extension attribution
  conflictRules.ts      static heuristics for same-role extension overlap
  suggestionEngine.ts   turns profiles + conflicts + editor context into Suggestion[]
  DashboardPanel.ts      webview view provider (Activity Bar panel)
  types.ts               shared types
media/
  dashboard.css / .js    the webview UI (vanilla HTML/CSS/JS, no framework)

Running it

npm install
npm run build      # or: npm run watch

Then press F5 in VS Code (with this folder open) to launch an Extension Development Host with ExtSherlock installed. Open the ExtSherlock icon in the Activity Bar, and click Run Deep Scan.

Configuration

Setting	Default	Description
extsherlock.sampleIntervalMs	2000	Background sampling cadence for the vitals strip.
extsherlock.deepScanDurationMs	8000	Length of a Deep Scan profiling window.
extsherlock.autoDeepScanOnLagSpike	true	Auto-trigger a Deep Scan on a lag spike.
extsherlock.lagSpikeThresholdMs	120	Lag (ms) considered a "spike".

Packaging

npm install -g @vscode/vsce
npm run package    # produces extsherlock-0.1.0.vsix