Optimize TextEncoder::encode

[anonrig]

It's possible to optimize and speed up TextEncoder.encode() by a size of 7x by following the implementation from cloudflare/workerd#5448.

cc @nodejs/performance

[ChALkeR]

TextEncoder perf drastically dropped in 25 compared to 22

[RafaelGSS]

Also related #183

[ChALkeR]

Here are my benchmarks
Smth happened with Node.js TextEncoder.encode with recent changes
Also, when doing any benchmarks, it's better to test both ascii and non-ascii modes, separately

E.g. Node.js TextDecoder is significantly faster on ASCII-only input than browsers, but slower on Unicode.
Note: here, all instances are in utf8 mode, just some input is ascii-only.

[targos]

@ChALkeR Can you share the benchmark code?

[ChALkeR]

@targos yes, it also tested a bunch of other impls, I need to detach it from those other impls first to make it stand-alone

For now I confirmed that this is not caused by allocUnsafe regression, as the numbers are still the same on 25.1.0

[ChALkeR]

@targos https://gist.github.com/ChALkeR/f49edd556ff3d08638eb3e81b43ce178

Output (cleaned up a bit):

chalker@Nikitas-MacBook-Air bytes % nvm use 22
Now using node v22.21.1 (npm v10.9.4)
chalker@Nikitas-MacBook-Air bytes % node --expose-gc benchmarks/utf8.pure.bench.js
utf8toString, ascii: TextDecoder x 2,197,802 ops/sec @ 455ns/op (292ns..850μs)
utf8toString, ascii: TextDecoder (loose) x 2,493,766 ops/sec @ 401ns/op (250ns..7ms)
utf8toString, ascii: Buffer x 2,624,672 ops/sec @ 381ns/op (250ns..463μs)

utf8toString, complex: TextDecoder x 22,728 ops/sec @ 43μs/op (39μs..386μs)
utf8toString, complex: TextDecoder (loose) x 22,110 ops/sec @ 45μs/op (38μs..7ms)
utf8toString, complex: Buffer x 23,311 ops/sec @ 42μs/op (38μs..297μs)

utf8fromString, ascii: TextEncoder x 1,428,571 ops/sec @ 700ns/op (333ns..4ms)
utf8fromString, ascii: Buffer x 1,269,036 ops/sec @ 788ns/op (416ns..4ms)

utf8fromString, complex: TextEncoder x 60,010 ops/sec @ 16μs/op (14μs..1384μs)
utf8fromString, complex: Buffer x 61,316 ops/sec @ 16μs/op (13μs..840μs)

chalker@Nikitas-MacBook-Air bytes % nvm use 25
Now using node v25.1.0 (npm v11.6.2)
chalker@Nikitas-MacBook-Air bytes % node --expose-gc benchmarks/utf8.pure.bench.js
utf8toString, ascii: TextDecoder x 1,893,939 ops/sec @ 528ns/op (333ns..894μs)
utf8toString, ascii: TextDecoder (loose) x 2,463,054 ops/sec @ 406ns/op (250ns..147μs)
utf8toString, ascii: Buffer x 2,506,266 ops/sec @ 399ns/op (291ns..139μs)

utf8toString, complex: TextDecoder x 22,951 ops/sec @ 43μs/op (38μs..345μs)
utf8toString, complex: TextDecoder (loose) x 23,400 ops/sec @ 42μs/op (38μs..212μs)
utf8toString, complex: Buffer x 22,194 ops/sec @ 45μs/op (38μs..1169μs)

utf8fromString, ascii: TextEncoder x 385,356 ops/sec @ 2μs/op (2μs..1203μs)
utf8fromString, ascii: Buffer x 1,406,470 ops/sec @ 711ns/op (417ns..1392μs)

utf8fromString, complex: TextEncoder x 46,503 ops/sec @ 21μs/op (18μs..1234μs)
utf8fromString, complex: Buffer x 47,030 ops/sec @ 21μs/op (18μs..468μs)

utf8fromString, ascii: TextEncoder regressed

[lemire]

There is definitively a performance problem. I quickly verified it for myself. @ChALkeR's results are solid.

Let us address it.

[targos]

From tests on my side, the main regression happens with version 24.0.0.

[ChALkeR]

There was an error in the bench which affected utf8toString, ascii: Buffer rows, fixed that.
It was unrelated to the observed regression though
Also re-ran the benchmarks on charger

That didn't change the observation but changed the numbers a bit

[ChALkeR]

nodejs/node@b81697d (nodejs/node#58070) is the cause.
Using deprecated str->WriteUtf8 instead of str->WriteUtf8v2 restores the perf.

str->WriteUtf8:

utf8fromString, ascii: TextEncoder x 1522070 ops/sec @ 657ns/op (333ns..18ms)
utf8fromString, ascii: Buffer x 1377410 ops/sec @ 726ns/op (458ns..2ms)

utf8fromString, complex: TextEncoder x 54549 ops/sec @ 18μs/op (16μs..1748μs)
utf8fromString, complex: Buffer x 45378 ops/sec @ 22μs/op (18μs..4ms)

str->WriteUtf8v2:

utf8fromString, ascii: TextEncoder x 379507 ops/sec @ 2μs/op (2μs..3ms)
utf8fromString, ascii: Buffer x 1367989 ops/sec @ 731ns/op (417ns..4ms)

utf8fromString, complex: TextEncoder x 46522 ops/sec @ 21μs/op (19μs..1968μs)
utf8fromString, complex: Buffer x 44340 ops/sec @ 22μs/op (18μs..7ms)

There are more places that use WriteUtf8V2, are they also degraded perhaps?

[anonrig]

Yes. We can avoid this by using valueview in the referenced pull request.

[jasnell]

We should first try reaching out to the v8 team to see if there is anything we can do about the perf regression with the WriteUtf8V2 API.

@ChALkeR:

There are more places that use WriteUtf8V2, are they also degraded perhaps?

I'd be very surprised if they weren't.

[ChALkeR]

This seems to be an overkill when we know that the input width is 1 byte:

https://github.com/nodejs/node/blob/f4145f04518f6da697344029a963e24b95ef4276/deps/v8/src/objects/string.cc#L1109-L1112

Old impl optimizes it here with an & 0x80 check:

https://github.com/nodejs/node/blob/f4145f04518f6da697344029a963e24b95ef4276/deps/v8/src/api/api.cc#L5767-L5785

This template is missing a similar memcpy optimization for kSourceIsOneByte + mask check:

https://github.com/nodejs/node/blob/f4145f04518f6da697344029a963e24b95ef4276/deps/v8/src/strings/unicode-inl.h#L209-L213

[jasnell]

@erikcorry ... Just FYI in case you have any insight here. tl;dr it looks like there's a significant performance regression from the original WriteUtf8 to WriteUtf8V2