fix(amazonq): Reduce plugin start-up latency

[tsmithsz]

Problem

Performance analysis of the Amazon Q extension revealed significant startup latency issues, with the extension taking over 9 seconds to fully initialize. A detailed timing analysis identified several critical bottlenecks in the startup sequence, particularly around resource caching, LSP initialization, and feature configuration. These bottlenecks negatively impact user experience during IDE startup and extension activation.

Solution

• File: extension.ts
  • Call activateAmazonqLsp for everyone unless that person is using AL2 and they do not have glibc patch
  • Remove activateInlineCompletion since it is for the old inline completion
• File: basicCommands.ts
  • Added early return check to avoid duplicate registrations
• File: regionProfileManager.ts
  • Reduced polling interval from 1500ms to 500ms
• File: featureConfig.ts
  • Added debouncing mechanism to prevent duplicate API calls
  • Added time-based throttling with 5-second minimum interval
• File: resourceCache.ts
  • Added fast-path cache check to avoid locking for fresh cache hits

Testing

Performance testing was conducted to measure the impact of the optimizations on Amazon Q extension startup time. Tests were performed on both a test package workspace and an empty workspace, with multiple runs to ensure consistency.

Test Results

Production Build (Latest):

• Tests Package: 8.1s, 9.7s, 8.8s, 9.7s (Average: 9.1s)

• Empty Workspace: 8.9s, 10.1s, 10.0s, 8.8s (Average: 9.5s)

Optimized Build (This PR):

• Tests Package: 6.7s, 7.6s, 7.5s, 8.9s (Average: 7.7s)

• Empty Workspace: 6.9s, 7.6s, 6.8s, 7.6s (Average: 7.2s)

Performance Improvement

• Tests Package: 15.4% faster startup (9.1s → 7.7s)

• Empty Workspace: 24.2% faster startup (9.5s → 7.2s)

• Overall Average: 19.8% improvement in startup time

The optimizations show consistent performance gains across different workspace types. The reduced startup time enhances user experience by making the extension more responsive during IDE initialization.

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

• This pull request modifies code in src/* but no tests were added/updated.
  • Confirm whether tests should be added or ensure the PR description explains why tests are not required.
• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
  • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
  • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.