Skip to content

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

Merged
Carl723000 merged 1 commit into
ClaudeCodeUsage:mainfrom
jackyyangjq:perf/cache-usage-date-formatter
Sep 23, 2026
Merged

Carl723000 merged 1 commit into
ClaudeCodeUsage:mainfrom
jackyyangjq:perf/cache-usage-date-formatter

Conversation

@jackyyangjq

@jackyyangjq jackyyangjq commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Summary

formatUsageDate called toLocaleDateString once per table row and chart point,
which constructs a new Intl.DateTimeFormat on every call. This is the same cost
#109 removed from dateKeys, in the dashboard rendering path, which #109 and
#111–#113 don't touch. It showed up at 3–8% self time in extension-host profiles
captured while the dashboard was rendering.

This PR caches the formatter per locale and options. When no date field is
requested, it explicitly adds the numeric year/month/day default that
toLocaleDateString applies, so the output is unchanged.

Micro-benchmark (zh-CN, 20k labels): ~31 µs → ~1.1 µs per label.

Linked issues

Relates to #99

Type of change

  • Bug fix (non-breaking) → fix (patch)

How was this tested?

  • Added a test comparing formatUsageDate with toLocaleDateString for all
    eight UI locales and seven option shapes (including dateStyle, weekday,
    explicit zones, and a time-only option), daily and monthly, on both the first
    (uncached) and second (cached) call. With the default-date-field handling
    removed, the test fails, so it covers that edge case.
  • npm test: 1066/1067 pass. The one failure is
    real Claude filesystem events flow through manifest, index, and dashboard refresh
    (5 s timeout in extensionWindowActivity.test). It also fails 1 run in 5 on
    unmodified main, so it looks like a pre-existing flaky test.

Checklist

  • npm run compile is clean
  • CHANGELOG.md updated
  • No new runtime dependencies
  • No user-facing strings, settings or documented behaviour changed, so the i18n
    and README items don't apply.

🤖 Generated with Claude Code

formatUsageDate called toLocaleDateString once per table row and chart
point, constructing a fresh Intl.DateTimeFormat each time. That is the
same per-call cost ClaudeCodeUsage#109 removed from dateKeys, and it showed up at 3-8%
self time in extension-host profiles captured while the dashboard was
rendering.

Formatters are now cached per locale and options. When no date field is
requested, the numeric year/month/day default that toLocaleDateString
applies is added explicitly, so output stays identical. A new test
compares the result against toLocaleDateString for all eight UI locales
across several option shapes, including the cached second call.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

🤖 Automated first-pass review

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

To help with review, please ensure the change summary, tests, and any user-facing documentation or localization updates are included.


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

@Carl723000
Carl723000 merged commit 02f9ed8 into ClaudeCodeUsage:main Sep 23, 2026
5 checks passed
@Carl723000

Copy link
Copy Markdown
Collaborator

Thanks @jackieyangjq for your first contribution to Claude Code Usage! The formatter cache addresses a measured dashboard hotspot, and the tests cover all eight UI locales plus the less obvious date-option cases. I appreciate the clear benchmark and careful behavior check. Merged after the Node, UI, and package checks passed.


🤖 Generated with OpenAI Codex

@Carl723000 Carl723000 mentioned this pull request Sep 23, 2026
7 of 11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants