diff options
| author | João Távora <joaotavora@gmail.com> | 2026-05-24 03:26:19 +0100 |
|---|---|---|
| committer | João Távora <joaotavora@gmail.com> | 2026-05-24 04:23:51 +0100 |
| commit | 7892ae5eaf4c22a3209a8c44c6267004653c5691 (patch) | |
| tree | 4740ec244fba688d5b8f2bc3729f28e49eb80a35 /java/incrementing-version-code | |
| parent | 12eec781ed69c4fc7611e8c9a1953ad33da98a0c (diff) | |
Fix pathological slowness in flex completion
The 'completion-regexp-list' optimization in
completion--flex-all-completions-1, a cheap pre-filter via a trivial
regexp, performs very poorly for longer patterns and strings, so drop
it. That alone recovers fairly decent performance for the flex
completion when compared to the 'hotfuzz' point of reference.
We then recover the cheap rejection with an O(N+M) pre-check in the
Fcompletion__flex_cost_gotoh C scorer. This kicks in the common case
(completion-ignore-case is nil) and pays off especially when the table
is already a list and 'all-completions' needn't cons.
See:
https://lists.gnu.org/archive/html/emacs-devel/2026-04/msg01081.html
https://lists.gnu.org/archive/html/emacs-devel/2026-05/msg00519.html
* lisp/minibuffer.el (completion--flex-all-completions-1): Remove
regexp pre-filter.
* src/minibuf.c (Fcompletion__flex_cost_gotoh): Add subsequence
pre-check.
Diffstat (limited to 'java/incrementing-version-code')
0 files changed, 0 insertions, 0 deletions
