idea: LSP enrichment as a continuous background lane, with a much faster bulk path

[pbednarcik]

Not a bug report, more of a direction I'd like to explore and discuss, with numbers from
my production C# monorepo (~117k nodes) now that the lane actually works (#603 + #604).

What the first working pass showed

The first complete enrichment pass produced 33,841 LSP-origin edges at confidence 1.0:
26,178 calls, 3,426 implements, 2,944 overrides, 1,187 extends. It confirmed 5,474
heuristic edges and added 26,782 new ones. The server itself was flawless the whole time,
0 errors, 0 reconnects. Compiler-grade edges at this volume change what the graph can
answer.

But the pass took 84.5 minutes to reach 22% node coverage and then hit its deadline
(partial: true, 24,620 of 110,908 candidates). That's on a 16-core machine with plenty
of RAM, against a repo that is honestly not that big, and the sweep started from a
workspace that was fully loaded in about 30 seconds. Under real working conditions
(branch switches, files moving around) a pass this slow never finishes. The world changes
faster than the sweep covers it.

Why I think it's slow, and what I'd like to try

24,620 nodes in 5,069s is about 5 nodes/second. My working assumption (not profiled yet)
is that this rate comes from the protocol, not from compute: the sweep pays several
JSON-RPC round trips per node (hover, definition, references, call hierarchy) over one
stdio connection, so both sides plausibly spend most of the wall clock waiting on each
other. Worth verifying with a profile before optimizing. The ideas below don't depend on
which half dominates, roughly in order of leverage:

1. Bulk-export instead of per-node interrogation. For a batch sweep, use the compiler
   as a compiler: one pass over the loaded solution's semantic models can emit every
   call/implements/overrides/extends binding in roughly the time of a build. Minutes for
   the whole workspace instead of hours at 5 nodes/s. LSP then stays for what it is good
   at: incremental, per-change updates on a warm server. On the Roslyn side this could be
   a small companion exporter, and other compilers have equivalents.
2. Sweep only where heuristics are uncertain, by default. Most of the 110k candidates
   are edges the resolver already binds at high confidence. Prioritizing
   ambiguous/unresolved targets would deliver most of the correction value at a fraction
   of the requests (the pass already prioritizes unresolved-demand, narrowing the
   candidate set outright would go further). The exhaustive sweep that also re-checks
   confident edges is still worth keeping, but as an opt-in mode: it is the only pass
   that audits high-confidence heuristic edges instead of trusting them, and it pairs
   naturally with the disagreement ledger below. Same opt-in posture as eager LSP and the
   C# resolver helper.
3. Persist sweep progress and invalidate incrementally. Today the pass is one-shot
   and the next full pass starts over. Remembering per-node coverage, resuming across
   passes, and re-sweeping only changed files after a branch switch turns "never
   finishes" into "converges and stays fresh".
4. Ordering. The graph went queryable at ~7 minutes; the sweep then ran another 84
   minutes inside the warmup window, holding the daemon in "warming" long after every
   query worked. I'd spawn LSP after the cheap passes land and run the sweep strictly in
   the background at low priority. Nothing should gate on it.
5. Wire up refuted plus a disagreement log. EnrichResult.EdgesRefuted is declared
   and logged but, as far as I can tell, never set anywhere. So an LSP answer that
   disagrees with a heuristic edge changes nothing today. Wiring it, ideally with a
   per-edge record of disagreements (edge, heuristic tier/confidence, LSP verdict), makes
   the lane self-auditing and shows exactly which heuristic tiers mis-bind most.

The division of labor this is aiming at

Heuristics build the complete, fast, no-build graph. The compiler-backed lane owns the
long tail that would be very complex to reimplement by hand: overload resolution with
implicit conversions, flow-dependent typing, and especially source-generator output (code
that never exists as text in the repo, invisible to any text-based extractor, while the
compiler sees it natively). Heuristics leave the hard cases honestly unresolved and the
lane upgrades them continuously in the background. Instant availability plus
compiler-grade accuracy that compounds, without an 84-minute tax.

Happy to prototype any of these on this monorepo and report numbers.

[zzet]

Hey @pbednarcik, the problem with the enrichment tax is not fully resolved (and not in all languages). I'd be happy if you could prototype a solution. Having someone with a real 117k-node C# monorepo and actual numbers is worth a lot more than me guessing at what's slow. A few things I dug up that should save you time, because some of this is already built and one of the causes is somewhere you didn't look. 84 minutes tax is too expensive, and I'd be happy to resolve it, but I have at least 3 meaningful (and big by size) features I'd like to ship sooner rather than later.

Two of the five are already done

№3 (persist progress, resume incrementally) already works. Nodes get stamped once enriched; the stamp lives in the store and survives restarts, and the stamp filter is pushed down into SQL so stamped files drop out of the candidate list entirely. Edited files re-parse into fresh nodes, lose the stamp, and get re-swept — which is exactly the "only re-sweep what changed after a branch switch" behaviour you're asking for. So your partial: true run at 22% didn't throw anything away; the next pass picks up the other 78%.

There is one real hole, though: the stamp is a hover stamp, but it's used as the resume key for every phase. So if a node's call-hierarchy request failed transiently, it still counts as done and never gets retried. That part is worth fixing.

№4 (don't gate on the sweep) is also already the case — the daemon flips to ready before enrichment starts, and LSP spawns lazily. What does wait on enrichment is a specific set of heavy analyze kinds and a couple of resources.

The diagnosis is probably compute, not protocol

The JSON-RPC client is fully multiplexed — requests are keyed by id and only the byte write is serialised, so nothing is round-tripping one at a time. The sweep runs concurrently, documents stay pinned open per file (one didOpen per file, not per node), and it's 1–4 requests per node rather than four separate families.

Working back from your numbers, the mean request is about 0.31s at concurrency 6. That seems like normal Roslyn latency; I doubt it is the protocol overhead (but who knows).

Also: your 84.5 minutes is almost exactly what the code predicts. The budget is 10min + 40ms × candidates, capped at 90. With 110,908 candidates, that's 83.9 min. GORTEX_LSP_ENRICH_TIMEOUT overrides it. However, I still believe the 80+ mins tax if too high and it may mean potential need in revisiting the approach if the current is not working well (there definitely needed some profiling and open-minded experimentation).

№2 already exists — but it's broken for C#, and that's the real bug

Demand-gated sweeping is already the default, and the exhaustive mode is already opt-in. So the proposal as written is a no-op. But here's why it did nothing for you:

A file gets swept when demand > 0 || dispatch, and dispatch is just "does this file declare a type or an interface". In C# every file declares a class, so the disjunct is always true and the gate skips nothing. That's your 110k candidates right there.

The fix could be small - to make that predicate discriminating, the way the callable-side one already is (it checks abstract/virtual/override/implements rather than just the kind). Same bug hits Java, Kotlin and Swift, so it's worth more than just the C# win.

One caveat if you try it: the deadline is sized from the candidate count before gating, so cutting candidates also cuts the budget. Coverage should still improve, but I don't expect the two to move independently.

№5 is real and cheaper than you think

You're right that EdgesRefuted is never set. It's worse than that actually — RefuteEdge has no caller and the refute_unconfirmed config knob is plumbed three layers deep and never read.

But the detection already exists. The definition-rebind fallback asks the server for the definition at an unconfirmed call site, and when it disagrees it already rewrites the edge target and tags it rebound_from with the old target. So this is "split the rebind case out of the confirmed counter and emit a record that already exists", not "build a comparison path". Nothing in the lane deletes or downgrades edges today, which is probably fine to keep.

I'd actually do this one first. It's cheap, and it's the measuring instrument for everything else — you can't tell whether narrowing the sweep costs accuracy without it.

№1 — seems as the right direction, and there seems more scaffolding than you'd expect

You're pushing on the correct thing (thank you), and the architecture is already there. internal/semantic/goanalysis is exactly this for Go: one whole-module compiler load via go/packages, on by default. And internal/semantic/scip is a generic bulk lane that runs an indexer as a subprocess and ingests the index — its definitions-only mode was written for .NET coverage specifically.

So before writing a Roslyn companion exporter, it's worth seeing how far scip-dotnet gets you through the existing lane. You can wire it today with a semantic.providers entry named scip-csharp. It's undocumented and off by default, which is on us.

The actual gap isn't ingestion — it's edge kinds. That lane only emits calls, references and implements. No overrides, no extends. In your numbers that's ~4k of your 33.8k edges missing. Extending the relationship pass is very likely cheaper than a new exporter.

Order I'd suggest

Different from yours, mostly because of what's already built:

1. №5 — cheap, and it makes everything else measurable.
2. The dispatch predicate fix — small diff, probably your biggest immediate win, and it's the real version of №2.
3. Bump MaxParallel and read the existing counters — settles compute-vs-protocol for free.
4. №1 via SCIP + the missing edge kinds rather than a new exporter.
5. Skip №3 and №4 apart from the stamp-granularity hole.

Your framing of the division of labour is right and matches how the Go lane already works — heuristics for breadth, compiler for the hard tail. Source-generator output is a genuinely good argument for it that I hadn't weighted properly.

Happy to review whatever you prototype. If you want to start with the dispatch predicate I can point you at the exact spot.

[pbednarcik]

Hey @zzet, Yes I am actually thinking about to start with the dispatch predicate.