Skip to content

[repo-assist] perf: reuse singleton JavaScriptMetricsAnalyzer instance in analyzeFile() - #578

Draft
github-actions[bot] wants to merge 1 commit into
mainfrom
repo-assist/improve-js-analyzer-singleton-20260828-baf989092ecd88f8
Draft

[repo-assist] perf: reuse singleton JavaScriptMetricsAnalyzer instance in analyzeFile()#578
github-actions[bot] wants to merge 1 commit into
mainfrom
repo-assist/improve-js-analyzer-singleton-20260828-baf989092ecd88f8

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

🤖 This PR was created by Repo Assist, an automated AI assistant.

Summary

Both sibling analyzers, typescriptAnalyzer.ts and tsxAnalyzer.ts, already reuse a module-level singleton instance in their analyzeFile() static factory to avoid allocating a new analyzer object (and its underlying Tree-sitter parser wiring) on every call — this was called out explicitly in code comments as a deliberate optimization. javascriptAnalyzer.ts was missed when that pattern was introduced and still did return new JavaScriptMetricsAnalyzer().analyzeFunctions(sourceText); on every invocation.

This PR applies the identical, already-proven singleton pattern to javascriptAnalyzer.ts for consistency, eliminating an unnecessary object allocation on every provideCodeLenses call for JavaScript files.

Why it is safe

JsLikeMetricsAnalyzer (the shared base class) resets its mutable per-analysis state at the start of each top-level function analysis using a save/restore pattern, so reusing a singleton instance across calls is safe — exactly the same reasoning already documented and relied upon by typescriptAnalyzer.ts/tsxAnalyzer.ts.

Trade-offs

None identified. This is a pure internal refactor with no behavioral or API changes.

Test Status

  • npm run compile: passes
  • npm run lint: passes
  • npm run test:unit: 236 tests passing, coverage 98.71/94.99/99.1/98.71 (thresholds 95/88/97/95)
  • npm test (vscode-test): not run in this sandbox (no network access to download the VS Code test binary) — expected/known limitation; CI has network access and will verify.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

  • releaseassets.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "releaseassets.githubusercontent.com"

See Network Configuration for more information.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
Comment /repo-assist to run again

Add this agentic workflow to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@42c2ab5b4e4c9273534c39259b2e0df7f20f07e9

…le()

Sibling analyzers (typescriptAnalyzer.ts, tsxAnalyzer.ts) already reuse a
module-level singleton in analyzeFile() to avoid allocating a new analyzer
object on every call. javascriptAnalyzer.ts was missed in that earlier pass
and still allocated a fresh instance per call. This aligns it with the
already-proven pattern used by its siblings.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions Bot added a commit that referenced this pull request Aug 28, 2026
…alyzeFile()

Applies the same module-level singleton pattern already used by the
JS/TS/TSX analyzers (see #578) to the remaining five language analyzers.
Each previously allocated a new analyzer instance on every analyzeFile()
call; since analyzeFunctions() resets all mutable state (nesting,
complexity, details) at the start of each top-level function analysis,
reusing one instance per language is safe and avoids unnecessary
allocations on every file analyzed.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants