Intrepid/prometeu-studio
Intrepid/prometeu-studio
4
0
Fork 0
Code Pull Requests Activity
prometeu-studio/discussion/workflow/agendas/AGD-0051-pbs-lsp-performance-cache-and-snapshots.md
bQUARKz 099857b636
implements PLN-0137 (1/7) diagnostic-source 
Lock DSC-0066 on Q1-A and Q2-A. Retire AGD-0048 through AGD-0056
into AGD-0069, DEC-0058, and PLN-0137.

Published editor diagnostics use the bound frontend language id as
source. For PBS that is pbs. The stable compiler code stays in code
and is not copied into source. Related locations, phase, and repair
payload stay unpublished.
2026-09-22 08:11:06 +01:00

2.3 KiB
Raw Blame History

id ticket title status created resolved decision tags
AGD-0051 pbs-lsp-performance-cache-and-snapshots PBS LSP Performance Cache and Snapshots abandoned 2026-07-15
studio
lsp
vscode
compiler-pbs
editor
performance
caching

Pain

Domain owner: studio/lsp

Several PBS LSP requests rebuild or reanalyze substantial project state, which can become slow or jittery as projects grow and as richer features are added.

Context

The current bridge favors correctness and simplicity by invoking compiler pipeline analysis for diagnostics and editorial documents. A complete LSP needs snapshot caching, invalidation, cancellation, and predictable latency.

Open Questions

  • What is the canonical project/document snapshot boundary for LSP requests?
  • Which requests can reuse semantic read surfaces safely across document changes?
  • How should cancellation, stale responses, and background reanalysis be handled?

Options

Option A - Request-local analysis

  • Approach: Keep each LSP request self-contained and rebuild analysis as needed.
  • Pro: Simple, deterministic, and less stateful.
  • Con: Latency grows with project size and feature richness.
  • Maintainability: Good for correctness, weak for interactive performance.

Option B - Project snapshot cache

  • Approach: Maintain per-project analysis snapshots with document overlays, invalidation, and cancellation-aware request handling.
  • Pro: Required for responsive definition, references, rename, and semantic tokens.
  • Con: Introduces lifecycle complexity and stale-result risks.
  • Maintainability: Strong if snapshot ownership and invalidation are explicit.

Tradeoffs

A complete LSP needs shared state, but shared state must not leak stale analysis into edits. The decision is about the boundary, not just caching.

Recommendation

Prefer Option B before implementing workspace-wide features like references and rename.

Discussion

Define snapshot lifecycle, invalidation triggers, and cancellation policy.

Resolution

Aposentada em 2026-09-22. O tema foi consolidado em AGD-0069 / DSC-0066. Este texto não é normativo.

Next Step

Decide whether snapshot caching is a prerequisite for references/rename or can be staged later.