Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Long codegraph_explore queries are slow on a large index, so the prompt hook times out

Aperta
  • Qualcosa non va?
#2,620 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
20/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
sqlite, typescript
Ambito
backend, performance

Direzione di ricerca

The proposed fix is already available in commit 1d6f44d on the linked branch, and the issue says it was previously #2621. Review findRelevantContext, the searchNodes and getAllNodeNames paths, and scorePathRelevance; start by comparing that commit with main. The payload names __tests__/explore-term-search-cost.test.ts for coverage; done means the optimizations preserve output and ranking while reducing long-query latency.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

The Claude Code prompt hook times out on long prompts (a pasted log, a skill body): codegraph_explore cost grows with the number of distinct words in the query, and on a large index each word is expensive.

Setup: Linux, v1.6.2 and current main. One index over ~150 Java/Kotlin/TS repos: 19.5k files, 389k nodes, 757k edges, 1.1 GB db.

Cause. findRelevantContext runs searchNodes (FTS, then the LIKE and fuzzy fallbacks) and up to four findNodesByNameSubstring calls per extracted term, with no cap on terms. A 1.7k-char Oracle log gives 132 terms: 1712 SQL calls, 16 s of SQL (v1.6.2, per-statement timing):

statement calls total per call
name LIKE '%x%' (findNodesByNameSubstring) 294 7.3 s 25 ms
searchNodesLike (%x% on name/qualified_name) 78 3.4 s 43 ms
SELECT DISTINCT name (searchNodesFuzzy → getAllNodeNames) 63 3.2 s 51 ms
getDominantFile aggregation 1 1.1 s
FTS 236 0.6 s 2.6 ms

Plus JS: scorePathRelevance re-splits every query word for every scored result (~2.5 s on a 3k-char query).

Fix: commit 1d6f44d on retsamekohC:perf/explore-term-search (was #2621). Output byte-identical to main on all 6 test prompts; __tests__/explore-term-search-cost.test.ts covers the memo invalidation (sync, other connection, rolled-back transaction, rebind) and fuzzy ranking vs a full scan.

  1. FTS joins nodes on the TEXT id; nodes_fts is external-content with content_rowid='rowid', so a rowid join gives the same rows 2.5-3x faster.
  2. getAllNodeNames is documented as cached but is not; memoized per change stamp, like getDominantFile.
  3. Fuzzy fallback only scans names whose length is within maxDist of the query.
  4. scorePathRelevance caches the per-word split.

codegraph prompt-hook, same index copy, ms:

prompt main main + fix
short question 2,540 2,390
Oracle log, 1.7k chars 19,700 14,500
markdown, 3k 46,000 31,300
Java source, 3k 30,300 20,600
markdown, 10k 120,000 72,000
Java source, 10k 69,000 42,000

Not in the fix, your call:

  • The LIKE scans dominate what is left. An in-memory index of distinct lowercased names (one \n-joined string, indexOf per term, ASCII-only case folding to match SQLite LIKE) answers findNodesByNameSubstring in ~2 ms instead of 25 ms with identical rows; qualified_name can be matched on its alphanumeric segments, since a [a-z0-9] term cannot span a separator. Needs invalidation in the long-lived server (the same change stamp would do). With this, a per-process getDominantFile cache on disk, and the PR's changes, v1.6.2 runs the prompts above in 5.5 / 6.7 / 7.0 / 13.4 / 12.9 s. I run this as a --require preload for the hook; happy to turn it into a PR if you want the approach.
  • prompt-hook is a new process per prompt, so the getDominantFile memo never hits there: ~1 s on every prompt on this index.
  • codegraph_explore rejects queries over 10,000 chars, and prompt-hook passes the whole prompt, so a longer prompt silently gets nothing. Truncating in prompt-hook would keep the beginning.
  • Unrelated, noticed on the way: the dominant file of this index is a vendored moment-with-locales.js, so the core-directory boost favors a third-party library.
Lingua principale
C
Stelle
73.2k
Fork
4.7k
Merge medio
4h 46m
PR unite (30g)
478

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di colbymchenry/codegraph

Tutte le issue di colbymchenry/codegraph

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.