perf: bound residual resolver superlinearity across builtin and dynamic profiles #53

New issue

Open

opened 2026-07-28 22:06:08 +02:00 by buildagent · 1 comment

buildagent commented 2026-07-28 22:06:08 +02:00

Member

Copy link

Current state

The first investigation found three missing indexes and reduced large-corpus resolve time substantially:

• rust-analyzer: ~64s to ~25s;
• django: ~87s to ~25s;
• scoped watcher passes improved by 2.4x to 10.9x.

The change was semantics-preserving across more than one million compared ref rows.

The issue remains open because the acceptance target was not met. Resolve-stage throughput at tier 3 is still roughly 3.1x to 7.9x below tier 1, and the fitted exponent improved only from ~1.86 to ~1.55.

#65 is the concrete worst-case blocker: tier 1R and C# partial resolution still exhibit quadratic fan-out. This issue owns the residual end-to-end scaling model after such individual stages are repaired.

Goal

Establish and enforce a resolver cost model that remains practical as files, refs, duplicate names, languages, plugin packages and cross-language bridges grow.

The runtime-plugin architecture makes this more important: #77 introduces additional profiles, capabilities and bridge candidate sets. No dynamic resolver algorithm may ship without entering the same cost accounting.

Required decomposition

Measure each stage independently on tier-1, tier-3 and adversarial duplicate-name corpora:

• pool construction;
• tier 1a/1b/locality;
• qualifier/type-FQN passes;
• receiver/member passes;
• C# partial and other profile algorithms;
• reachability/tier 3;
• dynamic bridge passes;
• ref-count and symbol-edge rebuild;
• generation-scoped resolve under #78.

For each stage record:

• input ref groups;
• candidate and anchor rows;
• materialized relation sizes;
• actual work units;
• elapsed CPU/wall time;
• degradation/budget outcome;
• active language/profile/package generation.

A single total wall time cannot identify regression ownership.

Design constraints

• Equality-join materialization is preferred over correlated pattern evaluation.
• Every fan-out stage has an estimate and hard work budget.
• Budget degradation is payload-visible and preserves the last good active generation during plugin activation.
• Query-plan shape gates forbid known large-table correlated scans.
• Raw resolution percentage never gates performance work.
• Optimizations compare id-independent target projections, not only counts.
• Dynamic and builtin evidence use the same bounded resolver engine; package profiles cannot inject SQL or custom unmetered algorithms.

Remaining known headroom

Re-evaluate after #65:

• repeated import normalization and segment work;
• duplicate package-tail/file-key materialization;
• qualifier stem/file path pattern work;
• superlinear enclosing-symbol lookup in symbol-edge rebuild;
• SQLite plan stability without ANALYZE;
• incremental resolve scopes vs full generations;
• dynamic influence/provenance predicate overhead from #77.

Each optimization needs cold/incremental equivalence and phantom==0.

Baselines

Integrate with #41/#45:

• committed deterministic structural/work counters;
• recorded stage timings and RSS;
• generous hard no-hang ceiling;
• readable diffs when blessing a changed work baseline;
• tier-3 and dynamic-plugin corpora.

Machine timing is noisy; work-unit growth and query-plan shape are the primary gates. Wall clock remains an operational ceiling.

Acceptance

1. #65’s concrete quadratic stages are resolved or safely budgeted first.
2. Per-stage cost/work telemetry exists for every resolver algorithm, including plugin bridges.
3. No measured stage has an unexplained superlinear work curve over the committed scale suite.
4. Tier-3 throughput is within 2x of the comparable tier-1 workload, or the residual difference is decomposed and accepted with an explicit product ceiling.
5. Large plugin generation activation completes or fails/degrades without replacing the prior active generation.
6. Target projections remain identical on non-degraded runs and phantom_count stays zero.
7. Regressions are caught by work/plan baselines rather than depending on a lucky quiet runner.

## Current state The first investigation found three missing indexes and reduced large-corpus resolve time substantially: - rust-analyzer: ~64s to ~25s; - django: ~87s to ~25s; - scoped watcher passes improved by 2.4x to 10.9x. The change was semantics-preserving across more than one million compared ref rows. The issue remains open because the acceptance target was not met. Resolve-stage throughput at tier 3 is still roughly 3.1x to 7.9x below tier 1, and the fitted exponent improved only from ~1.86 to ~1.55. #65 is the concrete worst-case blocker: tier 1R and C# partial resolution still exhibit quadratic fan-out. This issue owns the residual end-to-end scaling model after such individual stages are repaired. ## Goal Establish and enforce a resolver cost model that remains practical as files, refs, duplicate names, languages, plugin packages and cross-language bridges grow. The runtime-plugin architecture makes this more important: #77 introduces additional profiles, capabilities and bridge candidate sets. No dynamic resolver algorithm may ship without entering the same cost accounting. ## Required decomposition Measure each stage independently on tier-1, tier-3 and adversarial duplicate-name corpora: - pool construction; - tier 1a/1b/locality; - qualifier/type-FQN passes; - receiver/member passes; - C# partial and other profile algorithms; - reachability/tier 3; - dynamic bridge passes; - ref-count and symbol-edge rebuild; - generation-scoped resolve under #78. For each stage record: - input ref groups; - candidate and anchor rows; - materialized relation sizes; - actual work units; - elapsed CPU/wall time; - degradation/budget outcome; - active language/profile/package generation. A single total wall time cannot identify regression ownership. ## Design constraints - Equality-join materialization is preferred over correlated pattern evaluation. - Every fan-out stage has an estimate and hard work budget. - Budget degradation is payload-visible and preserves the last good active generation during plugin activation. - Query-plan shape gates forbid known large-table correlated scans. - Raw resolution percentage never gates performance work. - Optimizations compare id-independent target projections, not only counts. - Dynamic and builtin evidence use the same bounded resolver engine; package profiles cannot inject SQL or custom unmetered algorithms. ## Remaining known headroom Re-evaluate after #65: - repeated import normalization and segment work; - duplicate package-tail/file-key materialization; - qualifier stem/file path pattern work; - superlinear enclosing-symbol lookup in symbol-edge rebuild; - SQLite plan stability without ANALYZE; - incremental resolve scopes vs full generations; - dynamic influence/provenance predicate overhead from #77. Each optimization needs cold/incremental equivalence and phantom==0. ## Baselines Integrate with #41/#45: - committed deterministic structural/work counters; - recorded stage timings and RSS; - generous hard no-hang ceiling; - readable diffs when blessing a changed work baseline; - tier-3 and dynamic-plugin corpora. Machine timing is noisy; work-unit growth and query-plan shape are the primary gates. Wall clock remains an operational ceiling. ## Acceptance 1. #65’s concrete quadratic stages are resolved or safely budgeted first. 2. Per-stage cost/work telemetry exists for every resolver algorithm, including plugin bridges. 3. No measured stage has an unexplained superlinear work curve over the committed scale suite. 4. Tier-3 throughput is within 2x of the comparable tier-1 workload, or the residual difference is decomposed and accepted with an explicit product ceiling. 5. Large plugin generation activation completes or fails/degrades without replacing the prior active generation. 6. Target projections remain identical on non-degraded runs and phantom_count stays zero. 7. Regressions are caught by work/plan baselines rather than depending on a lucky quiet runner.

buildagent added the

performance

Priority

Medium

severity/medium

labels 2026-07-28 22:06:12 +02:00

buildagent referenced this issue 2026-07-28 22:06:30 +02:00

test: scale ceilings for graph caps, resolver fan-out and dynamic plugin generations #41

buildagent commented 2026-07-29 00:57:39 +02:00

Author

Member

Copy link

Fixed — but two of my earlier claims were wrong, corrected below

Root cause: three missing indexes, not algorithmic cost

The "O(refs × candidates) is irreducible" hypothesis is refuted, with identical output produced for a fraction of the CPU:

1. symbols had no index on parent_id. Every m.parent_id = par.id AND m.name = ? join (tier 1R identifier decisions, tier 1R self-receiver, tier 1Q parent-anchored candidates) fell back to idx_symbols_file_span and scanned the parent's whole file. Measured on rust-analyzer: 121,234,431 symbol rows visited to emit 6,747 — 86,861 (binding, parent) pairs × ~1,396 symbols/file. That one statement was 37% of a 70s resolve.
2. temp.symbol_buckets could not be name-joined. Its WITHOUT ROWID PK is (file_id, name, lang, method_only), so tier 3's b.name = st.name AND b.lang = fr.lang had no path and SQLite inverted the plan into SCAN b (33k buckets) × SEARCH fr BY lang (1.5k files) — a cross product. 26s of 70s on rust-analyzer, 66s of 96s on django. This is I025's failure mode recurring: a name-join against a WITHOUT ROWID temp table.
3. temp.file_keys / temp.file_pkg had no indexes, so SQLite built an AUTOMATIC COVERING INDEX per consuming statement.

The change

m0023_symbols_parent_name_index (persistent symbols(parent_id, name)), plus four temp indexes built inside resolve_ref_targets_in_tx. No re-heal — an index changes no resolution. No ANALYZE: measured, it makes the re-heal 2.8× slower (9.4s → 26.3s) even with the indexes, because sqlite_stat1 pushes the planner back onto worse plans. That dependency is now pinned by a test asserting no sqlite_stat1 is ever generated, rather than living only in a doc comment.

CORRECTION 1 — I overstated the speedup

I reported 91.4s → 25.1s (3.6×) and 105s → 24.4s (4.3×). Those "before" baselines were taken against plain HEAD, which also lacked the #52 fix, so they conflated two changes. Holding #52 constant, the isolated #53 contribution is:

repo	before	after	speedup
rust-analyzer	64.1s	24.6s	2.6× (resolve stage 58.9s → 19.4s)
py-django	87.2s	24.6s	3.5× (resolve stage 79.2s → 17.8s)

Scoped passes — what a watcher actually runs — improve more: rust-analyzer 13,983ms → 5,821ms (2.4×), django 20,123ms → 1,842ms (10.9×).

CORRECTION 2 — "within ~2× between tiers" does NOT hold

That was this issue's acceptance criterion and I claimed it was met. It isn't. Resolve-stage throughput after the change: tier-1 ranges 55k–138k refs/s; tier-3 is rust-analyzer 17.5k and py-django 26.0k. Fastest tier-1 / slowest tier-3 = 7.9×; even the slowest tier-1 (ts-zod) vs rust-analyzer is 3.1×.

A log-log fit of resolve time vs refs across all 9 corpus repos: exponent 1.86 → 1.55. The superlinearity is reduced, not removed.

So this issue should not be closed as "scaling fixed". The indexes were the dominant term and are worth shipping on their own, but a residual super-linear component survives. Remaining known headroom, none of it attempted here:

• the import_norm precompute (IMPORT_SEGMENTS recomputes 7 nested REPLACE() per candidate×import probe) — projected the resolve stage to ~14s CPU;
• de-duplicating file_pkg to distinct pkg_tail before the GLOB, and driving qual_stem_files off file_keys instead of f.path GLOB;
• rebuild_symbol_edges is also superlinear (0.27s → 6.68s, 24.6×) via a correlated enclosing-symbol subquery — ~7% of wall, worth its own issue.

Correctness: verified, not assumed

Matching resolved-ref counts is not proof — the same count could bind to different targets. An adversarial review built two binaries differing only by this change and compared four id-independent projections (refs, symbols, ref_count, symbol_edges, targets rendered path#name@line) across all 9 corpus repos: 1,036,264 ref rows, zero differing rows. Per-tier counters identical. Also verified: 5-step incremental histories converge identically; a deliberate ANALYZE plan-drift stress still yields a byte-identical projection; and 24,394 rows of production read-side SQL are unchanged.

Tie-break safety is proven structurally, not just measured: every ON CONFLICT DO NOTHING insert's conflict-target PK is exactly the GROUP BY of its feeding SELECT, so a within-statement conflict is impossible and cross-statement order is tier order in Rust, not row order.

Costs

• idx_symbols_parent_name: +32% on isolated symbol INSERT (0.257s → 0.339s for 35k rows) — ~0.3% of total wall, below noise end-to-end.
• DB size +0.9% (rust-analyzer 105.4MB → 106.3MB), peak RSS +2.6% (236.8 → 242.9MB). Both are recorded metrics in target/corpus/scale-*.json, not gates — but they need re-baselining.

Acceptance

• root cause identified (query plan, not algorithmic) — with EQP before/after
• refs/s at tier-3 within ~2× of tier-1 — NOT met (3.1–7.9×); superlinearity reduced 1.86 → 1.55
• tier-3 wall clock recorded in the scale suite
• no phantom introduced — workspace suite green, corpus mutation guard 0 rebinds

## Fixed — but two of my earlier claims were wrong, corrected below ### Root cause: three missing indexes, not algorithmic cost The "O(refs × candidates) is irreducible" hypothesis is **refuted**, with identical output produced for a fraction of the CPU: 1. **`symbols` had no index on `parent_id`.** Every `m.parent_id = par.id AND m.name = ?` join (tier 1R identifier decisions, tier 1R self-receiver, tier 1Q parent-anchored candidates) fell back to `idx_symbols_file_span` and scanned the parent's **whole file**. Measured on rust-analyzer: **121,234,431 symbol rows visited to emit 6,747** — 86,861 (binding, parent) pairs × ~1,396 symbols/file. That one statement was 37% of a 70s resolve. 2. **`temp.symbol_buckets` could not be name-joined.** Its `WITHOUT ROWID` PK is `(file_id, name, lang, method_only)`, so tier 3's `b.name = st.name AND b.lang = fr.lang` had no path and SQLite inverted the plan into `SCAN b (33k buckets) × SEARCH fr BY lang (1.5k files)` — a cross product. 26s of 70s on rust-analyzer, **66s of 96s on django**. This is **I025's failure mode recurring**: a name-join against a `WITHOUT ROWID` temp table. 3. **`temp.file_keys` / `temp.file_pkg` had no indexes**, so SQLite built an `AUTOMATIC COVERING INDEX` per consuming statement. ### The change `m0023_symbols_parent_name_index` (persistent `symbols(parent_id, name)`), plus four temp indexes built inside `resolve_ref_targets_in_tx`. No re-heal — an index changes no resolution. **No `ANALYZE`**: measured, it makes the re-heal 2.8× *slower* (9.4s → 26.3s) even with the indexes, because `sqlite_stat1` pushes the planner back onto worse plans. That dependency is now pinned by a test asserting no `sqlite_stat1` is ever generated, rather than living only in a doc comment. ### CORRECTION 1 — I overstated the speedup I reported 91.4s → 25.1s (3.6×) and 105s → 24.4s (4.3×). Those "before" baselines were taken against plain HEAD, which also lacked the #52 fix, so they conflated two changes. Holding #52 constant, the isolated #53 contribution is: | repo | before | after | speedup | |---|---|---|---| | rust-analyzer | 64.1s | 24.6s | **2.6×** (resolve stage 58.9s → 19.4s) | | py-django | 87.2s | 24.6s | **3.5×** (resolve stage 79.2s → 17.8s) | Scoped passes — what a watcher actually runs — improve more: rust-analyzer 13,983ms → 5,821ms (2.4×), django 20,123ms → 1,842ms (10.9×). ### CORRECTION 2 — "within ~2× between tiers" does NOT hold That was this issue's acceptance criterion and I claimed it was met. It isn't. Resolve-stage throughput after the change: tier-1 ranges 55k–138k refs/s; tier-3 is rust-analyzer 17.5k and py-django 26.0k. **Fastest tier-1 / slowest tier-3 = 7.9×**; even the slowest tier-1 (ts-zod) vs rust-analyzer is **3.1×**. A log-log fit of resolve time vs refs across all 9 corpus repos: exponent **1.86 → 1.55**. The superlinearity is **reduced, not removed**. So this issue should **not** be closed as "scaling fixed". The indexes were the dominant term and are worth shipping on their own, but a residual super-linear component survives. Remaining known headroom, none of it attempted here: - the `import_norm` precompute (`IMPORT_SEGMENTS` recomputes 7 nested `REPLACE()` per candidate×import probe) — projected the resolve stage to ~14s CPU; - de-duplicating `file_pkg` to distinct `pkg_tail` before the GLOB, and driving `qual_stem_files` off `file_keys` instead of `f.path GLOB`; - `rebuild_symbol_edges` is *also* superlinear (0.27s → 6.68s, 24.6×) via a correlated enclosing-symbol subquery — ~7% of wall, worth its own issue. ### Correctness: verified, not assumed Matching resolved-ref counts is not proof — the same count could bind to different targets. An adversarial review built two binaries differing **only** by this change and compared four id-independent projections (refs, symbols, `ref_count`, `symbol_edges`, targets rendered `path#name@line`) across all 9 corpus repos: **1,036,264 ref rows, zero differing rows.** Per-tier counters identical. Also verified: 5-step incremental histories converge identically; a deliberate `ANALYZE` plan-drift stress still yields a byte-identical projection; and 24,394 rows of production read-side SQL are unchanged. Tie-break safety is proven structurally, not just measured: every `ON CONFLICT DO NOTHING` insert's conflict-target PK is exactly the `GROUP BY` of its feeding SELECT, so a within-statement conflict is impossible and cross-statement order is tier order in Rust, not row order. ### Costs - `idx_symbols_parent_name`: **+32%** on isolated symbol INSERT (0.257s → 0.339s for 35k rows) — ~0.3% of total wall, below noise end-to-end. - DB size **+0.9%** (rust-analyzer 105.4MB → 106.3MB), peak RSS +2.6% (236.8 → 242.9MB). Both are *recorded* metrics in `target/corpus/scale-*.json`, not gates — but they need re-baselining. ### Acceptance - [x] root cause identified (query plan, not algorithmic) — with EQP before/after - [ ] **refs/s at tier-3 within ~2× of tier-1 — NOT met** (3.1–7.9×); superlinearity reduced 1.86 → 1.55 - [x] tier-3 wall clock recorded in the scale suite - [x] no phantom introduced — workspace suite green, corpus mutation guard 0 rebinds

buildagent referenced this issue 2026-07-29 11:40:15 +02:00

perf: rebuild_symbol_edges is superlinear — correlated enclosing-symbol subquery per resolved ref (0.27s -> 6.68s, 24.6x) #54

buildagent referenced this issue 2026-07-29 11:51:58 +02:00

test: wall-clock-bounded resolver tests flake under machine load (10s bound, observed failing at load ~45) #55

buildagent referenced this issue 2026-07-29 17:35:26 +02:00

test: wall-clock-bounded resolver tests flake under machine load (10s bound, observed failing at load ~45) #55

dhoyer referenced this issue from a commit 2026-07-29 21:25:54 +02:00

fix: sticky anchored resolution (#52) + resolver index scaling (#53)

dhoyer referenced this issue from a commit 2026-07-29 21:25:54 +02:00

docs: correct stale tier-3 measurements after the #53 indexes

dhoyer referenced this issue from a commit 2026-07-29 21:25:54 +02:00

test: bound resolver scaling by ratio, not wall clock (#55)

dhoyer referenced this issue from a commit 2026-07-29 21:25:54 +02:00

release: v0.9.0 — OSS corpus test system + resolver fixes (I039)

buildagent referenced this issue 2026-07-29 21:26:30 +02:00

I039: OSS corpus test system + the four defects it found (v0.9.0, schema v25) #58

buildagent referenced this issue from a commit 2026-08-03 14:06:57 +02:00

test: tier-3 scale ceilings over rust-analyzer and django (#41)

buildagent referenced this issue from a commit 2026-08-03 14:06:57 +02:00

I039: OSS corpus test system + resolver fixes (v0.9.0, schema v25) (#58)

buildagent referenced this issue 2026-08-05 10:15:12 +02:00

perf: rebuild_symbol_edges is superlinear — correlated enclosing-symbol subquery per resolved ref (0.27s -> 6.68s, 24.6x) #54

buildagent referenced this issue 2026-08-05 12:37:51 +02:00

perf/reliability: tier 1R and C# partial resolution scale quadratically and hide progress #65

buildagent changed title from perf: cold-index throughput degrades ~5-6x from tier-1 to tier-3 repos (time scales ~refs^1.7) to perf: bound residual resolver superlinearity across builtin and dynamic profiles 2026-08-26 13:38:21 +02:00

buildagent referenced this issue 2026-08-26 13:40:46 +02:00

test: scale ceilings for graph caps, resolver fan-out and dynamic plugin generations #41

buildagent added

Priority

High

and removed

Priority

Medium

labels 2026-08-26 13:42:25 +02:00

buildagent added a new dependency 2026-08-26 13:43:13 +02:00

#65 perf/reliability: tier 1R and C# partial resolution scale quadratically and hide progress

dhoyer referenced this issue from a commit 2026-09-01 12:08:48 +02:00

I064: measure at the reported 235-project scale

buildagent referenced this issue 2026-09-05 12:53:06 +02:00

No per-call timeout on the MCP-to-daemon path, and no elapsed_ms for a tool call — a slow query is a silent hang with no operator surface #142

buildagent referenced this issue 2026-09-05 12:53:16 +02:00

symbol_edges has no index on to_id and symbols has none on ref_count, so reverse-edge queries full-scan #143

buildagent referenced this issue 2026-09-05 14:13:23 +02:00

symbol_edges has no index on to_id and symbols has none on ref_count, so reverse-edge queries full-scan #143

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

p1-integration

p0-integration

release/v0.32.2

release/v0.32.1

epic-i072-release-032

windows-installer

i269b-registry-truth

probe-win-baseline

fix/246-shadowed-imports

release/0.28.1

fix/review-followthrough-20260911

iwin-msvc-archive

v0.32.2

v0.32.1

v0.32.0

v0.31.2

v0.31.1

v0.31.0

v0.30.1

v0.30.0

v0.29.0

v0.28.3

v0.28.2

v0.28.1

v0.28.0

v0.27.1

v0.27.0

v0.26.1

v0.26.0

v0.25.0

v0.24.1

v0.24.0

v0.23.1

v0.23.0

v0.22.3

v0.22.2

v0.22.1

v0.22.0

v0.21.0

v0.20.3

v0.20.2

v0.20.1

v0.20.0

v0.19.5

v0.19.4

v0.19.3

v0.19.2

v0.19.1

v0.19.0

v0.18.1

v0.18.0

v0.17.0

v0.16.0

v0.15.3

v0.14.0

v0.13.3

v0.13.2

v0.13.1

v0.13.0

v0.12.0

v0.11.7

v0.11.6

v0.11.5

v0.11.4

v0.11.3

v0.11.2

v0.11.1

v0.11.0

v0.10.2

v0.10.1

v0.10.0

v0.9.0

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.1

v0.7.0

v0.6.1

v0.6.0

v0.5.21

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.2

v0.4.1

v0.4.0

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.0

Labels

Clear labels   

code-review

  

correctness

  

dos

  

performance

  

security

  

severity/high

  

severity/low

  

severity/medium

  

tech-debt

  

Kind/Breaking

Breaking change that won't be backward compatible

  

Kind/Bug

Something is not working

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Feature

New functionality

  

Kind/Security

This is security issue

  

Kind/Testing

Issue or pull request related to testing

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

No labels

code-review

correctness

dos

performance

security

severity/high

severity/low

severity/medium

tech-debt

Kind/Breaking

Kind/Bug

Kind/Documentation

Kind/Enhancement

Kind/Feature

Kind/Security

Kind/Testing

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Status

Abandoned

Status

Blocked

Status

Need More Info

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Depends on

#65 perf/reliability: tier 1R and C# partial resolution scale quadratically and hide progress

h-dv/code-index

Reference

h-dv/code-index#53

No description provided.