Skip to content

perf(entry): create entry cache lazily - #2247

Merged
hrsh7th merged 1 commit into
hrsh7th:mainfrom
hood:perf/entry-lazy-caches
Nov 5, 2026
Merged

hrsh7th merged 1 commit into
hrsh7th:mainfrom
hood:perf/entry-lazy-caches

Conversation

@hood

@hood hood commented Nov 4, 2026

Copy link
Copy Markdown
Contributor

Closes #2241

Summary

  • entry.cache is created on first use (get_cache(self)). Resolving sets it back to nil instead of calling clear(), which has the same effect.
  • entry.resolved_callbacks is created on the first resolve call.
  • _get_word calls the uncached _get_overwrite while the entry is being built, so items with a textEdit don't create the cache straight away. It's a cheap pure calculation from insert_range and the context.
  • cache.new shares one metatable across all instances.

match_cache is still created up front, since every entry is matched.

Data

CPU time, best of 15–20. Benchmark in #2236.

Metric Before After
entry.new x20k, label only 30.2 ms 26.2 ms (-13%)
entry.new x20k, with textEdit 34.0 ms 28.6 ms (-16%)
Building entries, 6k items, isIncomplete 153.7 ms 131.9 ms (-14%)

Compatibility

entry.cache and entry.resolved_callbacks are now nil until first used. Nothing in this repo reads them directly, and a GitHub code search found no external plugins that do.

Testing

All 73 specs pass, luacheck reports 0 warnings, and touched files are formatted with stylua.

@hrsh7th

hrsh7th commented Nov 5, 2026

Copy link
Copy Markdown
Owner

thank you

@hrsh7th
hrsh7th merged commit 9db1d76 into hrsh7th:main Nov 5, 2026
njhoffman pushed a commit to njhoffman/nvim-cmp that referenced this pull request Nov 6, 2026
…db1d76)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.

perf: every entry allocates caches it rarely uses

2 participants