[auto:perf] ProtoToJsonld の schema.org 線形探索を索引化して約10倍高速化 (2026-07-27)

[nagata-yoshiteru]

@claude — 定期メンテナンス bot の自動タスク（効率化・高速化・省リソース化の安全な改善 PR）。エンドユーザーの問い合わせ起点ではありません。

🤖 bot 向けの詳細手順 — 人間は読まなくて OK（クリックで展開）

進め方（共通ルール）

• この Issue には Slack スレッド（slackmeta）はありません。CLAUDE.md のスレッド返信ヘルパー post_slack は使わないでください（返信先スレッドが無いため）。
• リポジトリの CLAUDE.md のルールに従い、新しいブランチで最小限の変更を行い、PR を作成してください（merge しない／デフォルトブランチへ直接 push しない／force-push しない）。
• リスクのある変更や挙動が変わる最適化は避けるか、PR 説明にトレードオフを明記。目ぼしい改善が無ければ所見をコメントしてクローズ。
• 作成する PR の説明本文に Closes #<この Issue の番号> を含めてください（merge 時に自動クローズされます）。
• コミット（PR 作成）を行った場合は、最後に下記「Slack 通知」の手順でチャンネルへ新規投稿してください。
• Issue を open のまま残す場合（PR を作って merge 待ち／所見コメントだけ残して人手判断に委ねる、のいずれか）は、仕事を終える前に gh issue edit <この Issue の番号> --title "<新しいタイトル>" で タイトルを「具体的に何を扱ったか」が分かる形に書き換えること。クローズする場合は不要（初期タイトルのままで OK）。
  • 先頭の [auto:perf] プレフィックスは必ず残す（ワークフローの重複チェックがこの前方一致で動くため）。末尾の (YYYY-MM-DD) も残しておくと履歴を追いやすい。
  • 例: [auto:perf] 効率化・省リソース化 (2026-06-24) → [auto:perf] /api/users の N+1 クエリ解消 (2026-06-24)

タスク: 効率化・高速化・省リソース化

コードベース全体を調べ、処理を 効率化・高速化・省メモリ／省リソース化 できる箇所がないか探してください。

• 例: 不要な計算・重複処理の削減、N+1 やループ内 I/O の解消、アルゴリズム／データ構造の改善、無駄なメモリ確保・コピーの削減、キャッシュ化・バッチ化、適切な非同期化など。
• 明確に有益で安全な改善があれば実装して PR を作成。可能なら簡単な計測やベンチで効果を示す。
• 挙動（出力結果）は変えないこと。変える必要がある場合は PR 説明に明記。
• 目ぼしい改善が無ければ、その旨をコメントしてクローズ。

重複の確認（PR を作る前に必ず・重要）

同じ提案を何度も作らないため、着手前に過去の bot 提案を確認する。

# 過去の同種メンテナンス Issue（オープン/クローズ両方）
gh issue list --state all --label "auto-perf" --limit 30 --json number,title,state,closedAt,url
# 直近の PR（オープン=レビュー待ち / クローズ=却下 or マージ済み）
gh pr list --state all --limit 50 --json number,title,state,url,headRefName

• 今回入れようとしている改善が、オープンな PR（レビュー待ち）や過去にクローズされた PR / Issue（＝一度見送られた、あるいは既にマージ済みで対応済み）と実質同じなら、同じ PR を作り直さない。
• 過去にクローズされた提案は「見送られた」ものとして尊重し、新たな根拠が無い限り蒸し返さない。
• 確認の結果、新しく提案できる内容が無い（見つかった候補がすべて既出＝オープン放置 or クローズ済みの焼き直し）場合は、PR を作らず、該当する既存 Issue / PR の番号を挙げて「既出のためスキップ」とこの Issue にコメントしてから、この Issue をクローズする。

---

Slack 通知（PR を作成した場合のみ・フォーマット厳守）

実際に PR を開いた場合のみ投稿します（変更が無く所見コメントのみのときは投稿不要）。
PR は必ず gh pr create で 本物の PR を作成すること。compare / ?quick_pull=1 の「作成用リンク」は PR ではないので 使わない。

• 通知先チャンネルID: C0B7T6B8X9R
• 下記の TEXT を そのまま厳守。可変は末尾 〇〇（内容の一言）だけで、絵文字・タグ・2つのリンク（リポジトリ／PR）は必ず含め、書式は変えないこと。
• リンクは Slack 記法 <URL|表示テキスト> を使う（リポジトリ名と PR 番号がクリック可能になる）。

# 1) 作成した PR の URL を取得（未作成なら作成。作成済みならそれを取得）
PR_URL="$(gh pr view --json url -q .url 2>/dev/null || gh pr create --fill)"
PR_NUM="${PR_URL##*/}"

# 2) フォーマット厳守で Slack へ新規投稿（thread_ts は付けない＝チャンネル直下）
TEXT="🤖 [定期メンテナンス/perf] <https://github.com/${GITHUB_REPOSITORY}|${GITHUB_REPOSITORY}> を効率化する <${PR_URL}|PR #${PR_NUM}> を作成しました（内容: 〇〇）"
curl -s -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json; charset=utf-8" \
  --data "$(jq -n --arg c "C0B7T6B8X9R" --arg x "$TEXT" '{channel:$c, text:$x}')"

[claude]

Claude finished @nagata-yoshiteru's task —— View job • claude/issue-22-20260726_210340 • [Create PR ➔](https://github.com/exdata-inc/dbp-schema/compare/main...claude/issue-22-20260726_210340?quick_pull=1&title=Issue%20%2322%3A%20Changes%20from%20Claude&body=This%20PR%20addresses%20issue%20%2322%0A%0AGenerated%20with%20%5BClaude%20Code%5D(https%3A%2F%2Fclaude.ai%2Fcode)

---

効率化・省リソース化 — PR を作成しました

• 過去の bot 提案の重複確認（auto-perf ラベルの Issue はこれが初回、既存 PR にも同種の提案なし）
• コードベース調査（ProtoToJsonld.py / build.rs / notebook / 生成物）
• cProfile でホットスポット特定
• 実装（出力バイト一致を検証）
• ベンチマークによる効果測定
• コミット・PR 作成・Slack 通知

PR: #23 — perf: ProtoToJsonld の schema.org 線形探索を索引化して約10倍高速化（出力は完全一致）

何が遅かったか

ProtoToJsonld.py（.proto → JSON-LD 変換）の実行時間の 約 79% が、schema.org 語彙（約 3,000 件）に対する線形探索でした。

関数	tottime	全体比
DbpOrSchema (1,626 回)	0.217s	59%
SearchSchema (376 回)	0.074s	20%
その他（JSON encode/decode 等）	0.077s	21%

1 クラス・1 プロパティごとに 3,000 要素のリストを先頭から走査していたため、定義数 × 語彙数で効いていました。

変更内容（ProtoToJsonld.py のみ）

• schemaid_index（@id → 添字の dict）を初回に 1 回構築し、SearchSchema / DbpOrSchema を O(n) → O(1) に。重複 @id は setdefault で最初のものを優先し、従来の「先頭ヒットを返す」挙動を厳密に維持
• SearchRdfs も索引化、addChildClass の全走査を dict.get() に
• ループ内で毎回生成していた list(...keys()) + IGNORE_MESSAGES を frozenset 定数に事前計算
• WriteJsonld の sorted(set(items), key=items.index)（list.index が O(n) で全体 O(n²)）を、等価かつ O(n) の dict.fromkeys(items) に
• 使用後の schema.org グラフ（origin / schemalist / response）を del して常駐メモリ削減

計測結果

ネットワーク取得を除外（schema.org の JSON-LD をローカルキャッシュして requests.get を差し替え）し、dbp_schema.proto と dbp_schema.ja.proto の両方を変換：

	実行時間（3 回）
変更前	0.322s / 0.329s / 0.325s
変更後	0.032s / 0.032s / 0.031s

約 10 倍高速化。 変換完了後の常駐メモリ（tracemalloc）は 8.7 MiB → 2.2 MiB。

出力の同一性

変更前後で生成し cmp でバイト比較 — dbp-schema.jsonld / dbp-schema.ja.jsonld ともにバイト単位で一致（リポジトリの既存ファイルとも一致）、標準出力の 288 行も一致。よって生成物ファイルへの差分はありません。

今回やらなかったこと

• ParseProto 内の jsondata 線形探索（O(n²)）は未着手。2 ファイル合計で約 6ms しか消費しておらず、パース状態機械の微妙な挙動（tmp_prop を append した直後に同じリストを検索する箇所など）に触るリスクに見合わないと判断しました。詳細は PR 説明に記載
• Rust 側（src/dbp_schema.rs は tonic-build の生成物）と build.rs、notebook には目立った改善余地なし

merge は人手でお願いします。Slack（C0B7T6B8X9R）へ通知済みです。

--- · branch: claude/issue-22-20260726_210340