Repository navigation
Indexing slowed 2.2x on pretix since #2163: matchDestructuredCallResult rescans the file for every call #2334
Description
Activity
- added a commit that references this issue
on Oct 5, 2026 - added 2 commits that reference this issue
on Oct 5, 2026 - added a commit that references this issue
on Oct 5, 2026 Thanks @bompus for the bisect and the profile. They pointed straight at the cause.
Fixed on
mainin #2362, and both parts of the report are covered:- The slowdown. Two checks that shipped in 1.6.2 redid whole-file work for every reference.
matchDestructuredCallResult(fix(resolution): a name destructured from a composable reaches what it returns #2163) stripped and scanned all the text above each bare call, as you found.jsFunctionLocalScope(fix(js): a name the calling function binds is its local #2226) also re-stripped the calling function for every lookup, and in a minified bundle that function's text is the whole file. Each file's destructured bindings are now read once and looked up by name, and a function is stripped once and cut at the reference's line. A call inside what the blanker reads as a regex literal, which in minified code is often a division, is handled exactly. The old per-call scan is only a fallback for rare edge cases. - The summary time.
indexAllandsyncnow report the whole run's wall time, resolution and linking included, so theinit/index/syncsummaries, the MCP auto-sync log and the telemetry duration bucket all describe the run they sit beside.
The graph is unchanged. Node, edge and
unresolved_refsdumps were byte-identical in every before and after run on pretix, mealie and CPython's bundled assets. A differential harness comparing the old and new code over about 1.3M fuzzed call positions found no difference. On pretix, process CPU went from 160 s to 89 s and wall time from 76 s to 44 s (medians of 4 interleaved runs on a heavily loaded box), and peak memory went from 2.47 GB to 1.93 GB. The summary now prints the run's real time:in 39.0sfor a 40 s run, wheremainprintedin 18.5sfor an 84 s run.pdf.worker.jsis over the 1 MB file limit, so it was never parsed. The pretix cost came fromd3.v6.jsandpdf.js.This ships in the next release, and you're credited in the changelog. Thanks also for flagging it in #2332. With #2344 that covers both halves of the slowdown since 1.6.2.
- The slowdown. Two checks that shipped in 1.6.2 redid whole-file work for every reference.
Indexing pretix (1,466 files) takes 19.9 s on
mainat6560052a(1.6.2), up from 8.3 s. Agit bisectover290e03f7..6560052apoints atcf449fda(#2163):codegraph initon pretixd03e4dbf(parent)cf449fda(#2163)6560052a(1.6.2)Each step was one run on Node 24 on a 16-vCPU WSL2 host, with
CODEGRAPH_NO_DAEMON=1and telemetry off. Across the nine runs the fast builds took 7.95 to 8.34 s and the slow ones 17.70 to 19.91 s.Cause.
matchDestructuredCallResultruns for every bare JS-family call in a file that containsconst {,let {orvar {. For each call it joins every line above the call, runsstripCommentsForRegexandblankStringContentsover that text, walks it a character at a time instackAt, and matches the binding regex across it. The work for a file grows with the square of its size. pretix ships bundled libraries undersrc/pretix/static/:pdfjs/pdf.worker.js(1.95 MB),d3/d3.v6.js(560 KB) andpdfjs/pdf.js(497 KB).A
node --cpu-profrun atcf449fdashows each of the six resolver workers busy for 15.7 s. Self time summed over all threads:stripCStyle: 12.7 sblankStringContents: 11.2 sconst {test and the binding regex: 3.6 smatchDestructuredCallResult: 2.5 sstackAt: 0.6 sPossible fix. Most calls in such a file don't go through a destructured name. Strip the file once, collect the local names its
const { … } = f(…)bindings introduce, cache that set per file, and return early whenref.referenceNameisn't in it. Only calls through a destructured name would then pay for the prefix scan, and the links found stay the same. My fork's port of this resolver does this.The summary line leaves out this time. For the 19.9 s run,
codegraph initprinted32,322 nodes, 81,229 edges in 1.7s. InindexAll(src/index.ts),nodesCreatedandedgesCreatedare recomputed after resolution, butdurationMskeeps the value fromorchestrator.indexAll, which covers extraction only. The printed time leaves out resolution and linking, which is where this slowdown happens, so the CLI output didn't show it.