Optimize TextEncoder::encode

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

TextEncoder perf drastically dropped in 25 compared to 22

Also related #183

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.

@ChALkeR

@ChALkeR Can you share the benchmark code?

@targos

@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

@targos

@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

@ChALkeR

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

Let us address it.

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

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

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?

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

@ChALkeR

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.

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

@erikcorry

@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

@drcarney66

Heh, i think @drcarney66's patch works...

                                                                               confidence improvement accuracy (*)     (**)    (***)
util/text-encoder.js op='encode' type='ascii' n=1000000 len=1024                      ***     31.43 %       ±1.92%   ±2.55%   ±3.33%
util/text-encoder.js op='encode' type='ascii' n=1000000 len=256                       ***     19.58 %       ±2.51%   ±3.34%   ±4.36%
util/text-encoder.js op='encode' type='ascii' n=1000000 len=32                          *      3.24 %       ±2.51%   ±3.35%   ±4.36%
util/text-encoder.js op='encode' type='ascii' n=1000000 len=8192                      ***    195.59 %       ±6.02%   ±8.10%  ±10.72%
util/text-encoder.js op='encode' type='one-byte-string' n=1000000 len=1024                    -0.68 %       ±1.33%   ±1.77%   ±2.30%
util/text-encoder.js op='encode' type='one-byte-string' n=1000000 len=256               *      2.18 %       ±1.73%   ±2.30%   ±3.00%
util/text-encoder.js op='encode' type='one-byte-string' n=1000000 len=32                      -1.49 %       ±3.80%   ±5.07%   ±6.63%
util/text-encoder.js op='encode' type='one-byte-string' n=1000000 len=8192              *     -1.80 %       ±1.46%   ±1.95%   ±2.54%
util/text-encoder.js op='encode' type='two-byte-string' n=1000000 len=1024                     0.85 %       ±1.11%   ±1.48%   ±1.93%
util/text-encoder.js op='encode' type='two-byte-string' n=1000000 len=256                     -1.10 %       ±1.39%   ±1.85%   ±2.40%
util/text-encoder.js op='encode' type='two-byte-string' n=1000000 len=32               **     -3.52 %       ±2.34%   ±3.12%   ±4.07%
util/text-encoder.js op='encode' type='two-byte-string' n=1000000 len=8192             **      1.94 %       ±1.32%   ±1.76%   ±2.30%
util/text-encoder.js op='encodeInto' type='ascii' n=1000000 len=1024                  ***   1270.28 %      ±37.24%  ±50.18%  ±66.62%
util/text-encoder.js op='encodeInto' type='ascii' n=1000000 len=256                   ***    347.51 %      ±12.64%  ±17.01%  ±22.56%
util/text-encoder.js op='encodeInto' type='ascii' n=1000000 len=32                    ***     31.33 %       ±3.36%   ±4.48%   ±5.85%
util/text-encoder.js op='encodeInto' type='ascii' n=1000000 len=8192                  ***   4540.69 %     ±190.78% ±257.12% ±341.35%
util/text-encoder.js op='encodeInto' type='one-byte-string' n=1000000 len=1024        ***     -6.23 %       ±2.66%   ±3.55%   ±4.62%
util/text-encoder.js op='encodeInto' type='one-byte-string' n=1000000 len=256         ***     -5.06 %       ±2.62%   ±3.48%   ±4.53%
util/text-encoder.js op='encodeInto' type='one-byte-string' n=1000000 len=32          ***     -7.09 %       ±3.40%   ±4.53%   ±5.91%
util/text-encoder.js op='encodeInto' type='one-byte-string' n=1000000 len=8192        ***     -4.74 %       ±1.23%   ±1.63%   ±2.13%
util/text-encoder.js op='encodeInto' type='two-byte-string' n=1000000 len=1024                -0.30 %       ±2.38%   ±3.17%   ±4.12%
util/text-encoder.js op='encodeInto' type='two-byte-string' n=1000000 len=256                 -0.80 %       ±2.60%   ±3.46%   ±4.51%
util/text-encoder.js op='encodeInto' type='two-byte-string' n=1000000 len=32           **     -3.97 %       ±2.41%   ±3.21%   ±4.17%
util/text-encoder.js op='encodeInto' type='two-byte-string' n=1000000 len=8192                 0.40 %       ±1.72%   ±2.29%   ±2.98%

@drives

Longer term, we can optimize the code that @drives optimized even further, not just for ASCII, but for the general case as well. There is @anonrig's work in the OP, but we will build better support in future releases of simdutf.

(This is not a criticism of @drives's excellent work. Just an indication that we can do even better in the future.)

Before patch:

utf8fromString, ascii: TextEncoder x 373832 ops/sec @ 2μs/op (2μs..2ms)
utf8fromString, ascii: Buffer x 1336898 ops/sec @ 748ns/op (458ns..4ms)

utf8fromString, complex: TextEncoder x 45483 ops/sec @ 21μs/op (19μs..6ms)
utf8fromString, complex: Buffer x 45777 ops/sec @ 21μs/op (20μs..3ms)

After patch:

utf8fromString, ascii: TextEncoder x 1510574 ops/sec @ 662ns/op (333ns..11ms)
utf8fromString, ascii: Buffer x 1360544 ops/sec @ 735ns/op (458ns..2ms)

utf8fromString, complex: TextEncoder x 45838 ops/sec @ 21μs/op (19μs..4ms)
utf8fromString, complex: Buffer x 45988 ops/sec @ 21μs/op (20μs..3ms)

The patch fixes the main regression from 22 to 24.

There seems to be some other things going on though, will also take a look later
22 was still faster on other usage:

utf8fromString, ascii: TextEncoder x 1,739,130 ops/sec @ 575ns/op (333ns..1362μs)
utf8fromString, ascii: Buffer x 1,620,746 ops/sec @ 617ns/op (416ns..310μs)

utf8fromString, complex: TextEncoder x 61,580 ops/sec @ 16μs/op (15μs..339μs)
utf8fromString, complex: Buffer x 60,953 ops/sec @ 16μs/op (14μs..343μs)

Ok, that patch is merged. I've been chatting with the v8 people about potential improvements to the general case using simdutf as much as possible and will follow up.

@jasnell

@jasnell @anonrig does Node.js want to cherry-pick that perhaps?)

Yes. Let's make sure to add lts-watch on the PR (unless manual backport to other V8 lines is needed).

I'm wondering if the fix would be the same for TextDecoder? #183

@RafaelGSS

@RafaelGSS Is #183 still relevant?
Also, ascii TextDecoder perf in Node.js already looks like a memcpy with check (I didn't look at impl though)

Non-ascii is 2x slower than Chrome and 2.3 slower than Firefox (ref: #192 (comment))
It couldn't be that the ascii fast path check is slowing down the non-ascii perf that much

I will re-do my benchmarks tonight!

@drcarney66

For TextEncoder:

If simdutf::validate_ascii has a version to return the max length of ascii prefix instead of true/false (i.e. the length at which it stopped being ascii), then patch by @drcarney66 could be optimized further to also memcpy ascii prefixes, in case if string has a long ascii prefix.
Non-ascii path is slow and could be likely improved ~7x as @anonrig said.
Ideally that also should happen on v8 side (same method), and not in Node.js -- that will fix other things too.
There is still some regression remaining from 22, but not so drastic anymore.
In both asci and non-ascii modes, by ~20-30%.

For TextDecoder:

ascii codepath is quite fast but likely could be faster
Non-ascii codepath is slow. Likely could be likewise improved ~7x.
Likely the logic with ascii prefixes could be also applied there

@ChALkeR

@ChALkeR

If simdutf::validate_ascii has a version to return the max length of ascii prefix instead of true/false

Yes:

  std::string bad_ascii = "\x20\x20\x20\x20\x20\xff\x20\x20\x20";
  simdutf::result res = simdutf::validate_ascii_with_errors(bad_ascii.data(), bad_ascii.size());
  if(res.error != simdutf::error_code::SUCCESS) {
    std::cerr << "error at index " << res.count << std::endl;
  }

But my overall message is that a lot of optimization work will be easier if you just wait a few months for the next simdutf releases. So I recommend waiting a few months before doing complicated work.

I'll have a PR that adds the v8 patch open a bit later today.

I rebased workerd after the optimization. cloudflare/workerd#5448 (comment) is still 30-70% faster for ascii inputs.

I strongly suspect there are additional improvements to be made on the v8 side to reclaim more of the perf loss before we explore further workarounds.

FYI: We had regressions for small strings and longer strings that weren't ascii in the one byte case, so I'm merging this. Has similar enough performance to simdutf + memcpy for the ascii case but bails out fast for all other cases.

Still some work to do but we're still working on it.

Related: nodejs/node#61041

Navigation Menu

Repository navigation

Optimize TextEncoder::encode #192

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Optimize TextEncoder::encode #192

Description

Activity

ChALkeR commented on Nov 3, 2025

RafaelGSS commented on Nov 3, 2025

ChALkeR commented on Nov 3, 2025

targos commented on Nov 4, 2025

ChALkeR commented on Nov 4, 2025

ChALkeR commented on Nov 4, 2025

lemire commented on Nov 4, 2025

targos commented on Nov 4, 2025

ChALkeR commented on Nov 4, 2025

ChALkeR commented on Nov 4, 2025

anonrig commented on Nov 4, 2025

jasnell commented on Nov 5, 2025

ChALkeR commented on Nov 5, 2025

jasnell commented on Nov 5, 2025

4 remaining items

jasnell commented on Nov 5, 2025

lemire commented on Nov 5, 2025

ChALkeR commented on Nov 5, 2025

drcarney66 commented on Nov 5, 2025

ChALkeR commented on Nov 5, 2025

RafaelGSS commented on Nov 5, 2025

ChALkeR commented on Nov 5, 2025

RafaelGSS commented on Nov 5, 2025

ChALkeR commented on Nov 5, 2025

lemire commented on Nov 5, 2025

jasnell commented on Nov 5, 2025

anonrig commented on Nov 6, 2025

jasnell commented on Nov 6, 2025

drcarney66 commented on Nov 19, 2025

ChALkeR commented on Dec 16, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions