Skip to content

perf: cached repeated strict token lookups per input - #178

Merged
alyldas merged 1 commit into
mainfrom
perf/cache-repeated-strict-tokens
Jul 23, 2026
Merged

perf: cached repeated strict token lookups per input#178
alyldas merged 1 commit into
mainfrom
perf/cache-repeated-strict-tokens

Conversation

@alyldas

@alyldas alyldas commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Cache positive and negative normalized strict-token lookup results within one top-level invocation.
  • Keep one- and two-token inputs on inline cache entries, then promote to a null-prototype dictionary bounded by the unique tokens in the current input.
  • Reuse compiled pattern and taxonomy metadata while preserving per-occurrence boundary checks, UTF-16 ranges, and scanner early stop.
  • Add regression coverage for repeated matches and misses, three-token promotion, boundary contexts, taxonomy filters, mutation between calls, and filter isolation.
  • Extend the focused strict lookup benchmark with repeated-match timing and exact anchored pattern-evaluation counts.

Validation

  • npm ci
  • npm test -- tests/strict-token-index.spec.ts tests/api.spec.ts tests/scanner.spec.ts tests/runtime-literals.spec.ts tests/normalization.spec.ts tests/internal-rules.spec.ts
  • npm run check
  • npm run benchmark:strict-lookup with the same harness on origin/main and this branch
  • npm run benchmark:profanity on origin/main and this branch with the same machine and command shape

Benchmark Evidence

Baseline origin/main:

  • createProfanityFilter(): 7.1879 avg ms
  • unique clean tokens: 1.0590 avg ms; 300 indexed evaluations per call
  • repeated clean tokens: 0.8885 avg ms; 300 indexed evaluations per call
  • repeated matches: 1.3303 avg ms; 300 indexed evaluations per call
  • strict early match: 0.1475 avg ms
  • strict late match after unique tokens: 0.3536 avg ms
  • general long clean: 0.9494 avg ms
  • general long late match with repeated clean text: 0.3700 avg ms

This branch:

  • createProfanityFilter(): 7.2239 avg ms
  • unique clean tokens: 1.1150 avg ms; 300 indexed evaluations per call
  • repeated clean tokens: 0.6630 avg ms; 1 indexed evaluation per call
  • repeated matches: 1.2902 avg ms; 1 indexed evaluation per call
  • strict early match: 0.1519 avg ms
  • strict late match after unique tokens: 0.4022 avg ms
  • general long clean: 0.8792 avg ms
  • general long late match with repeated clean text: 0.1680 avg ms

Repeated clean lookup improved by about 25.4%, repeated match analysis by about 3.0%, general long clean by about 7.4%, and the repeated long-late fixture by about 54.6%. The unique-token negative control measured about 5.3% overhead, with no change to its 300 required indexed evaluations; the cache is lazy for up to two distinct tokens and remains bounded by the current input.

Compatibility Notes

  • Public APIs, exports, scanner inputs, tokenization, normalization strategies, and dictionary formats are unchanged.
  • Strict rule precedence, taxonomy metadata, UTF-16 analyzer ranges, scanner code-point ranges, and occurrence-specific boundary decisions remain compatible.
  • Positive and negative entries live only inside one strict scan, so runtime mutation between calls and multiple filter instances cannot share stale cache state.
  • Boolean checks retain early stop, while analyze, censor, and streaming scans reuse lookup results without skipping occurrence-specific ranges.
  • Release Please PR chore(main): release 0.16.2 #175 remains open and is reserved for the single milestone release.

Closes #172

No publish, no merge, no tag/release.

@alyldas
alyldas merged commit b67b031 into main Jul 23, 2026
4 checks passed
@alyldas
alyldas deleted the perf/cache-repeated-strict-tokens branch July 23, 2026 10:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Cache repeated strict-token lookups within one input

1 participant