vim-patch:9.2.1034: NFA regexp matching is slow for ASCII text (#41642)

Problem:  NFA regexp matching is slower than necessary for ASCII text
          because two indirect function calls are made for every
          character.
Solution: Add an inline fast path for an ASCII byte that is not followed
          by a composing character (Julien Voisin).

The main loop of nfa_regmatch() fetched the current character and its
byte length with two calls through the mb_ptr2char and mb_ptr2len
function pointers on every character.  These pointers cannot be inlined,
yet for ASCII text, which is the common case, both merely return the byte
and a length of one.

Handle that case inline.  NUL is checked first so that reading the next
byte cannot go past the end of the line, and the "next byte is ASCII"
condition matches the check in utfc_ptr2len(), so a base character
followed by a composing character still falls through to the original
calls.

A "perf stat -e instructions" on a full scroll of a 60000 line C file with
syntax highlighting enabled shows an instructions count reduction of 4%.

closes: vim/vim#21179

58390ca285

Co-authored-by: Julien Voisin <julien.voisin@dustri.org>
This commit is contained in:
zeertzjq
2026-09-03 11:06:35 +08:00
committed by GitHub
parent 89837bdd72
commit aff123a5d4

View File

@@ -14275,8 +14275,17 @@ static int nfa_regmatch(nfa_regprog_T *prog, nfa_state_T *start, regsubs_T *subm
// Run for each character.
while (true) {
int curc = utf_ptr2char((char *)rex.input);
int clen = utfc_ptr2len((char *)rex.input);
int curc, clen;
// Fast path for an ASCII byte not followed by a composing
// character, matching the check in utfc_ptr2len(). Avoids two
// indirect calls for the common case.
if (rex.input[0] != NUL && rex.input[0] < 0x80 && rex.input[1] < 0x80) {
curc = rex.input[0];
clen = 1;
} else {
curc = utf_ptr2char((char *)rex.input);
clen = utfc_ptr2len((char *)rex.input);
}
if (curc == NUL) {
clen = 0;
go_to_nextline = false;