Extension causes high cpu load

Issue Type: Performance
Extension Name: claude-code-usage
Extension Version: 2.3.0
OS Version: Windows_NT x64 10.0.26200
VS Code version: 1.136.1

⚠️ Make sure to attach this file from your home-directory:
⚠️file:///c%3A/Users/mkgas/AppData/Local/Temp/GrowthJack.claude-code-usage-unresponsive.cpuprofile.txt

Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load

🤖 Automated first-pass reply

The configured analysis model did not return a usable analysis for this issue. The item has still been received and remains available for maintainer review.

To help with triage, please ensure the extension, VS Code, and operating-system versions plus anonymous diagnostic logs are included.

🤖 Posted automatically by CCU Bot — not a maintainer decision.

Thanks for the report. The referenced CPU profile was not attached, so the report does not yet identify which extension path is consuming CPU.

Please update to the latest Marketplace release. If the problem persists, attach both:

the GrowthJack.claude-code-usage-unresponsive.cpuprofile.txt file named in the report; and
the anonymous refresh: lines from Claude Code Usage: Show Diagnostic Logs during the spike.

Those diagnostics contain timings and counters, not prompts, paths, session IDs, credentials, or raw JSONL. Please also say whether the spike stops when Codex collection is disabled; that comparison helps distinguish the Claude and Codex processing paths.

We will keep this issue open pending that evidence rather than guessing at a Windows-specific root cause.

🤖 Generated with OpenAI Codex

fix: stabilize v2.3.2 dashboard interactions (#100)

Here is the profile that was missing, taken against a live pegged host rather than after the fact, plus a fix in #109.

Environment: VS Code 1.104, Windows 11, extension 2.3.3, ~1.4 GB of local history in ~/.claude/projects (645 JSONL files), 7 concurrent Claude Code sessions appending to it. The extension host held one core at 100% and 2 GB RSS for hours — measured 10.27 s of CPU per 10 s of wall clock.

The extension host starts with --inspect-port=0, so the profile can be taken without restarting anything: find the listening port for the host PID, confirm it at http://127.0.0.1:<port>/json/list, then Profiler.enable / setSamplingInterval / start / stop over the websocket. 6 s at 200 µs sampling, self time by node:

30.4%  resolveTimeZone      out/dateKeys.js:18
26.5%  partsInZone          out/dateKeys.js:28
18.3%  (anonymous)          out/claudeIncrementalIndex.js:902
 4.7%  (program)
 3.0%  analyzeLine          out/dataLoader.js:243
 2.6%  utf8Slice
 2.4%  estimateTokens       out/dataLoader.js:165
 1.5%  scanCodexJsonlLines  providers/codex/codexJsonlScanner.js:28
 1.3%  (idle)

Root cause: partsInZone builds a new Intl.DateTimeFormat on every call, and resolveTimeZone inside it builds another. Both run once per ingested record, so formatter construction — not parsing — dominates. On this history the key derivation runs at ~1,059 records/second; with the formatters memoised per zone it runs at ~167,982 (158x), producing identical keys.

On your Codex question: I did not test with Codex collection disabled, because the profile shows the hot path is not Codex-specific — dateKeys is shared by both providers and the Codex scanner itself is only 1.5% of samples. Disabling Codex would reduce the record count, not remove the per-record cost.

This is not Windows-specific either: it is the cost of Intl.DateTimeFormat construction multiplied by record count, so it grows with history size on any platform.

perf: memoise Intl formatters in date bucketing (#99) (#109)

perf: keep multi-file appends on the incremental path (#99) (#111)

perf: a new transcript no longer rebuilds the corpus (#99) (#112)

perf: window drift no longer forces a full rebuild (#99) (#113)

Another data point, this time on macOS, confirming this is not Windows-specific.

Environment: macOS 15.6 (Apple M4, 16 GB), VS Code 1.134.0, extension 2.3.3,
~1.3 GB of history in ~/.claude/projects (967 JSONL files), no Codex data.

VS Code showed the "extension is blocking other extensions" warning. It auto-captured
5 extension-host profiles between 10:04 and 10:13 today (1.5–6.4 s each). 97–99% of
samples are inside this extension, and the top two self-time entries in every one are:

Profile	Duration	`partsInZone`	`resolveTimeZone`
07470a	6.4 s	34.7%	30.5%
50828b	5.4 s	39.5%	36.0%
603af2	5.3 s	33.2%	31.4%
834681	3.8 s	29.0%	45.5%
54eee5	1.5 s	49.0%	31.8%

This matches the root cause fixed in #109, so it should go away once that ships
(together with #111–#113).

One extra hotspot none of those PRs touch: formatUsageDate in
src/usageDateLabels.ts shows up at 3–8% self time in the two dashboard-render
profiles. It calls Date.prototype.toLocaleDateString(locale, {...}) per row, which
also constructs a new formatter on every call. Caching an Intl.DateTimeFormat
per (locale, options) would apply the same fix there. Still present on main.

Happy to share the .cpuprofile files if useful.

perf: an appended file leaving the window stays incremental (ClaudeCo…

perf: memoise the dashboard date-label formatter (#99) (#115)

perf: an appended file leaving the window stays incremental (#99) (#114)

docs: changelog entry for the expired-file rebase (ClaudeCodeUsage#99)

@mkgaskin-ops

Post-release update: 2.5.0 is now available on Marketplace and Open VSX. It additionally fixes the large-group timestamp argument-stack overflow reported by @mkgaskin-ops in #126. That path could repeatedly fail refresh after a project exceeded the runtime's argument limit. The release includes 150,000-record regression coverage and bounded refresh-failure reporting.

This does not establish that every remaining high-CPU path is resolved. In particular, @rsyuzyov's original #127, #128 and #129 remain open and are being reviewed against the newly released source; their proposed deletion/rewrite/manifest gains are not included in 2.5.0. Thanks again to @rsyuzyov, @jackyyangjq, @jordanvalnet and @mkgaskin-ops for the profiling and reports.

Keeping this issue open. If CPU spikes persist on installed 2.5.0, the useful comparison is anonymous refresh: diagnostics, OS/VS Code versions, whether Content analysis/dashboard were enabled, and a redacted CPU profile if available. Please do not post raw conversation history, credentials or personal paths. If the extension is disrupting work, disabling it remains a reasonable temporary workaround.

🤖 Generated by OpenAI Codex as an automated first pass — not a maintainer decision.

perf: stat manifest files concurrently (ClaudeCodeUsage#99)

docs: changelog entry for concurrent manifest stat (ClaudeCodeUsage#99)

docs+test: changelog under Changed, wall-clock bound with margin (Cla…

fix: stop scheduling stats after a fatal scan error (ClaudeCodeUsage#99)

docs: keep the manifest-stat note under Unreleased (ClaudeCodeUsage#99)

perf: deleting a transcript no longer re-reads the whole history (Cla…

docs: changelog entry for deletion without rebuild (ClaudeCodeUsage#99)

docs: align deletion measurements, pin no-retag contract in test (Cla…

fix: restore ownership when a deletion meets an append (ClaudeCodeUsa…

perf: rewriting a transcript no longer re-reads the whole history (Cl…

docs: changelog entry for rewrite without rebuild (ClaudeCodeUsage#99)