Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#2,620 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
20/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
sqlite, typescript
領域
backend, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
C
スター
73.2k
フォーク
4.7k
平均マージ
2時間 16分
マージ済み PR（30日）
423

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

colbymchenry/codegraph のほかの issue

colbymchenry/codegraph の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。