[perf-scan] 2026-09-15 -- performance opportunities found

[github-actions]

Performance Scan - 2026-09-15

Automated scan of src/apm_cli/ for algorithmic performance anti-patterns.
1 finding identified.

Findings

[F] Sequential independent I/O -- src/apm_cli/registry/operations.py:292-310

• Current: O(n) sequential registry HTTP round-trips -- batch_fetch_server_info
  loops over server_references and calls
  self.registry_client.find_server_by_reference(server_ref) once per
  iteration, with no data dependency between iterations. Each call performs
  its own search_servers() + get_server() network request, so wall time
  grows linearly with server count. The sibling method
  check_servers_needing_installation (same class, lines 40-104) already
  solves the identical fan-out with a bounded ThreadPoolExecutor(max_workers=4),
  confirming this is an established, applicable pattern in this file.
• Proposed: O(n/max_workers) wall time using the same bounded
  ThreadPoolExecutor approach already used a few dozen lines above in the
  same class.
• Fix: Wrap the for server_ref in server_references: loop body in a
  ThreadPoolExecutor(max_workers=4) and use executor.map to fetch each
  server's info concurrently, mirroring check_servers_needing_installation's
  _check_one pattern, then populate server_info_cache from the results.

Scan coverage

• src/apm_cli/ (484 files scanned)
• Patterns checked: A (quadratic loops), B (linear scan in loop),
  C (unconditional expensive ops), D (redundant config parsing),
  E (heavy top-level imports), F (sequential independent I/O)

Generated by Daily Performance Scanner · copilot · auto · 112.2 AIC · ⌖ 6.03 AIC · ⊞ 10.1K · ◷

• expires on Sep 22, 2026, 1:38 AM UTC

[sergio-sisternes-epam]

This is an automated Daily Performance Scanner report with one finding: sequential independent registry I/O in MCPServerOperations.batch_fetch_server_info (src/apm_cli/registry/operations.py). The sibling method check_servers_needing_installation already uses a bounded ThreadPoolExecutor, so the proposed fix is a local reuse of that pattern, not a new concurrency design.

Advisory recommendation: accept as a bounded performance change. This comment is not scope approval, a release target, or an invitation to start a second implementation.

Existing thread facts (not granted by this advisory):

• A maintainer applied status/accepted and self-assigned.
• Open PR perf(registry): parallelize independent MCP server-info fetches #2983 already implements the scan's proposed wrap of the serial loop.
• There is still no <!-- apm-scope:v1 --> approval comment on this issue. Per CONTRIBUTING.md, the human approval record is that comment; the label alone is not the machine-readable record.

Suggested next step for a responsible maintainer: keep review on #2983 (submission order, per-ref None-on-exception, and thread-safety of the shared registry client). If machine-readable scope evidence is wanted, post a new unedited scope record on this issue rather than treating this advisory as approval.

Classification already present: type/automation and type/performance. Preserve both; do not collapse them. A useful extra label if a maintainer wants one is area/mcp-config (registry lookups during MCP install). No docs-site pages are implied.

---

Generated by autopilot-issue-triage-worker. This comment is AI-generated and may contain errors.

[github-actions]

This issue was automatically closed because it expired on 2026-09-22T01:38:50.307Z.

Closed by Workflow