Performance - Drastically improve worst case regex performance

[adam-arthur]

Problem:
Very poor performance when testing certain regexes due to unnecessary conversion to/from string/array.

Impact:
Some of the reporters in Vitest that depend on this code are extremely slow. (See: vitest-dev/vitest#2602)

Notes:
While time complexity of both operations is theoretically the same, seems the VM is optimizing string specific operations much better than the conversion back/forth.

Future:
In this case can run a single global regex on the entire string up front rather than re-allocating a new substring at each index. But for now this is simple and solves the issue.

[adam-arthur]

Please see for context:
vitest-dev/vitest#2602

[adam-arthur]

CC @sindresorhus

[sindresorhus]

.slice() operates on code units while the [...word] splits on codepoints. That's a subtle difference.

> '🌍'.slice(0, 2).length
< 2
> [...'🌍'].length
< 1

[adam-te]

Good catch, not too familiar with unicode/string particulars.

Will add a test to this effect and update PR

[adam-arthur]

Updated PR to respect unicode character lengths

[sindresorhus]

Will add a test to this effect and update PR

Missing the test

[moosemanf]

I would argue the test is "missing" bc basically every other test confirms the correct behaviour, isn't it? @sindresorhus

[gtm-nayan]

My profiler shows me that a significant amount of time is also spent in the ansiRegex() call inside strip-ansi. stripAnsi is being called for every "word" and each time it creates a new regex object. Might want to looks there as well, creating the regex in the module scope and then resetting its lastIndex before each use sounds like a fairly low hanging fruit.

[gtm-nayan]

Completely tangential but @adam-arthur can you please tell me what tool you're using for the per-line timings in #51 (comment) ?

[sindresorhus]

Bump :)