HermitCrab analysis: a per-word root-search cache cut Sena work 21.3% in the port; C# repeat-lookup share unmeasured
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 38/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- csharp
- 領域
- performance
調査の方向性
Read row 28 of the #490 ledger and the issue’s C# versus PanGloss comparison first. Measure the cost of repeated (stratum, shape) root-trie lookups on Sena in C# before implementing anything. Done means reporting whether that work share is material and, based on the result, whether to port the bounded per-word cache.
索引モデルが issue の本文から書いたものです。
説明
Claude-drafted.
A per-word root-search cache cut Sena work by 21.3% in the Rust port, but the C# record says repeated root lookups are only 0.5 to 3.3% of parser work. Whether C# has the same gap is unmeasured. Analysis branches that reach the same (stratum, shape) repeat the identical root-trie search.
Status: merged in the port; not built in C#.
What we know (port, work steps; parses identical on every completed word):
- Sena: 182,297,249 to 143,399,740 (-21.3%, measured before the edge index of #599 landed). Mbugwe -0.6%; Cebuano -0.1%, or -1.2% with an added enclitic; the other samples and fixtures about 0.
- It holds the raw ordered trie result per word, keyed by exact (stratum, shape), capped at 1 MiB (peak 1.04 MB on Sena), and is discarded after each word. Lexical-entry filtering, overlay and dedup still run on every lookup. A capped or timed-out search is never cached. A result is stored only if its search cost more than a hit is charged, so no path costs more.
- Ledger row 28 closed a similar C# cache: untraced C# makes 1.13 to 1.49 calls per distinct (stratum, shape).
- Inferred: the port's larger gain comes from charging a lookup per trie edge, which makes repeats dearer than in C#'s unit.
Not known: the share of C# work spent on repeated lookups on Sena.
Proposed change: measure that share first, on hc.dll, in lookups and work steps. Port the cache only if the share is material, and then only after an explicit decision against the no-memoization rule (ledger row 38): it is a bounded memo.
Related:
- PanGloss: sillsdev/PanGloss#92 (closed by PR sillsdev/PanGloss#96, merged).
- sillsdev/machine#599 (open); #490 (closed PR, retired record).
Next: count untraced repeated (stratum, shape) lookups and their work on Sena in hc.dll.
Evidence -- numbers, method
From PanGloss PR #96 and its lane report (single-threaded --stats).
| Grammar | Work before | Work after | Peak cache |
|---|---|---|---|
| Sena | 182,297,249 | 143,399,740 (-21.3%) | 1,042,524 B |
| Sena, with the port's edge index (#599) and cache together | 182,297,249 | 138,405,255 (-24.1%) | 1,042,524 B |
| Mbugwe, 1,636 completed words | 35,582,069,812 | 35,354,992,356 (-0.6%) | 1,048,396 B (cap 1,048,576) |
| Cebuano base | 5,395,400 | 5,392,090 (-0.06%) | 427,336 B |
| Cebuano with enclitic | 6,340,178 | 6,265,316 (-1.2%) | 427,336 B |
Cebuano rows compare against a build with the edge index but no cache. Seven Mbugwe words never complete on either build and are unverified. Cache bounds are conservative allocation estimates, not allocator measurements.
Surprising findings -- why this reopens a closed ledger row
Row 28 closed the cache because trace mode (which disables merging) had inflated the lookup count to 97,575 over 56 shapes. Untraced, repeat-lookup work was 0.5 to 3.3% of parser work (10.4% only on row 25's pre-fix bug); lookup was 1 to 12% of parser work. PanGloss merged a narrower version anyway: per word, exact key, capped, discarded after each word.
Lookup gap (search-cost round, open lead 14): on the slowest word of one private project, the port made 18 lookups on C#'s export against C#'s 49. Parses were identical and the cause was not investigated there. Ledger row 24 later attributed a related gap (18 lookups against 1,655 on the port's own snapshot) to a loading difference, not search. Neither figure is evidence about repeats in C#.
Sources -- pinned
- 主要言語
- C#
- スター
- 29
- フォーク
- 16
- 平均マージ
- 5日 21時間
- マージ済み PR（30日）
- 9
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
sillsdev/machine のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 28/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
メンテナーはふだん 1 日以内に返信
sillsdev/machine の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
libnativeapi/nativeapi#21 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 3 日以内に返信
-
enhancement P3 performance
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
thomhurst/TUnit#7380 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信