Skip to content

perf(english): name the featured dictionary so it lazy-loads - #223

Merged
ddehilster merged 1 commit into
VisualText:mainfrom
ddehilster:perf/english-feat-dict-lazy-name
Sep 22, 2026
Merged

ddehilster merged 1 commit into
VisualText:mainfrom
ddehilster:perf/english-feat-dict-lazy-name

Conversation

@ddehilster

Copy link
Copy Markdown
Member
en-full-feat.dict  ->  en-feat-full.dict

The engine loads a dictionary word by word, on demand, only when the file name ends in full before the extension. full has to be the last part of the name — so a file can contain the word and still be read whole at startup. en-full-feat.dict ended in feat, and was loaded eagerly for that reason alone.

The engine tells you which mode it is in

One file in kb/user, a 60-word input:

en-full-feat.dict   [READ dict files time= 2.09 sec]          ← and no other line
en-feat-full.dict   [Lazy-loading words from ...en-feat-full.dict]
                    [READ dict files time= 0.23 sec]

Same 8.3 MB of bytes. Same attributes on the node afterwards — a word still arrives with its vform, tense and number from the featured readings:

fox  ("noun" 1) ("verb" 1) ("pos num" 2) ("number" "singular") ("vform" "base") ("tense" "present")

Only the name and the timing change.

Why now

Nothing loads this file by name, so nothing breaks. It is worth doing now rather than later because the file is the source of truth for the English lexicon and is becoming more attractive to vendor into an analyzer — and the cost of the wrong name is paid by whoever does that first.

What is deliberately not in here

en-lemmas.kbb (2 MB), en-nouns.dict (2 MB) and en-roots.kbb (4 MB) are still named so that they load eagerly.

en-lemmas.kbb is the one that costs something today — EnglishPhrases and StatuteFrames both pull it in with loadkbb, and renaming it takes EnglishPhrases from 5.32 s to 0.70 s with byte-identical output over 52 inputs. But renaming it breaks both analyzers until they are updated, so it belongs with that change, not this one.

lazyload.md now lists which English files are lazy and which are not, with the measurements, so the next person does not have to find out by timing it.

🤖 Generated with Claude Code

en-full-feat.dict -> en-feat-full.dict

The engine loads a dictionary word by word, on demand, only when the file name
ends in "full" before the extension.  "full" has to be the LAST part of the
name, so a file can contain the word and still be read whole: en-full-feat.dict
ended in "feat", and was loaded eagerly for that reason alone.

The engine says which mode it is in, so it is easy to check.  One file in
kb/user, a 60-word input:

  en-full-feat.dict   [READ dict files time= 2.09 sec]     and no other line
  en-feat-full.dict   [Lazy-loading words from ...en-feat-full.dict]
                      [READ dict files time= 0.25 sec]

Same bytes, same attributes on the node afterwards.  A word still arrives with
its vform, tense, number and, since the frequency work, its freq_<pos>:

  jumped  verb  pos num=2  root=jump  vform=past  tense=past  freq_verb=34

Only the name and the timing change.

Nothing loads this file by name, so nothing breaks.  It is worth doing now
rather than later because the file is the source of truth for the English
lexicon and is becoming more attractive to vendor into an analyzer, and the
cost of the wrong name is paid by whoever does that first.

en-lemmas.kbb (2 MB), en-nouns.dict (2 MB) and en-roots.kbb (4 MB) are still
named so that they load eagerly.  en-lemmas.kbb is the one that costs something
today -- two analyzers load it with loadkbb -- but renaming it breaks them until
they are updated, so it goes with that change and not this one.  lazyload.md now
lists which English files are lazy and which are not, with the measurements.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ddehilster
ddehilster force-pushed the perf/english-feat-dict-lazy-name branch from a1acf3d to 0d0b868 Compare September 22, 2026 13:17
@ddehilster
ddehilster merged commit ee22685 into VisualText:main Sep 22, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant