TextEncoder and TextDecoder performance concern around all libraries / runtimes

[WebReflection]

What is the issue with the Encoding Standard?

I've been asked to file a new issue after this comment #333 (comment) and here I am doing that:

• no runtime on the server prefers standards API to convert JS UTF-16 based strings into UTF-8 compatible strings, yet our Operating Systems, files, the Web itself, runs over UTF-8 to maximize compatibility with all Programming Languages and avoid misleading, or error prone, conversions all over the place
• no library which goal is to serialize as binary data JS uses TextEncoder or TextDecoder if not just after trying to avoid both by all means because these are extremely slow, via encodeInto variants or not, compared to more or less accurate JS only solutions
• all JS only solutions are fast enough with laptops plugged in, but overall CPUs degrade 5X+ performance once devices are in battery save mode ... or better, all libraries perform extremely bad out of just JS code and it's not clear why these APIs are so slow compared to NodeJS, Bun or other JS runtime solutions that are not based on these APIs
• if all server runtimes need to avoid these APIs and SharedArrayBuffer + Atomics is used to convert JS references otherwise impossible to convert natively as binary, it's clear to me we're lacking a primitive which only purpose would be to return a buffer out of String.prototype.toUTF8Buffer() or any other named API which goal is to just do that without all the performance caveats behind the scene
• at the same time, it's not clear why every JS solution literally outperform these native APIs so that something might be really off behind these API implementations, as most libraries are based on RFC standards and has been proven to work for years bypassing TextEncoder or TextDecoder usage

As summary, it would be great to understand why these APIs are so slow and why there is no interest in having best performance backed in to transform strings as binary data and decode these.

Use cases:

• Atomics via SharedArrayBuffer where the only language these APIs speak is binary and views of buffers
• cross posting + cross programming language communication
• file handling where all APIs returns arrayBuffer but that's both async (usually) and yet needs conversion to text too if these are traveling
• leader tab patterns used to enable OPFS where data can only travel as binary to be fast enough, avoiding any encoding/decoding all over the place (buffers travel fast)
• serialization where to know the length of a JS string we need all sort of invariants to what byteLength could provide and yet, that would not solve the whole issue: we also need/want that buffer after

Thanks in advance for considering any alternative API that would boost performance or considering investigating how come we need to loop charCodeAt all over the Web to be sure we're either faster than native APIs, which goal supposed to be to simplify that encoding/decoding dance, or needed to compute the resulting length of a JS string, usually before needing that string as buffer anyway 🙏

[annevk]

At least some of the links you included in the previous comment indicated that there was only slowness observed for shorter inputs. But it was unclear to me how it compared across implementations. Are there benchmarks somewhere?

Seems like there should be more numbers here and profiling before designing new APIs.

[WebReflection]

there was only slowness observed for shorter inputs

define only ... that's the most common and world-wide spread use case when serializing objects, where each key length, even in Java, rarely is bigger than 64 chars (cbor-x) and even beyond that, all those libraries adopt strategies to decode faster by grouping binary data via their byteLength as serialized string to then optimize and cache all over the place everything that has already been encoded or decoded, with the lovely caveat that strings are not observable by FinalizationRegistry as these are primitives, so that most libraries bloat in RAM and can't predict strings usage across programs by any mean.

All benchmarks in those repositories or posts show that everyone needs to avoid TextEncoder or TextDecoder as repeatedly slow and all performance show that these are slow indeed compared to manual hand-crafting of buffered strings.

Moreover, cbor-x uses a /\u0080-\uFFFF/ regexp to instantly bail out of TextEncoder and you can read developers complaining about this encoding being slow ...

Accordingly, what do you need to see that encoding and decoding via these API is slow? A code-pen? Some basic snippet that uses console.time or ... what? Happy to provide what you are after, just please don't try to hide the issue here, because for real-world use cases those APIs slow on small inputs are the issue, not the feature.

---

edit P.S. I have tons of benchmarks using tons of libraries ... with TextEncoder and TextDecoder we're talking 2 to 10 times slower results ... I'd be happy to show those results to you too but I am worried the outcome would be "you are doing it wrong in your code" while the entire point of this issue is that nobody should do it wrong, they should use native APIs because these do it right but these gotta perform better than home-made solutions too or these become spooky, not helpful for broader use cases.

[WebReflection]

this is a very simple scenario where you can see (plugged in) TextEncoder based variant (and TextDecoder) in cbor-x, when it comes to not ASCII chars is always way slower and it's already weird to find that out ... JS implementations faster than native APIs ... but then try to unplug your laptop and check again results ... JS user-land degrades a lot in there, not so native APIs ... yet this is an issue nobody can state is not existent or not real!

The page shows nothing, you better open a tab, open console, then only after reach this Code Pen to see results: https://codepen.io/WebReflection/full/OPJzNyZ

---

edit if anyone needs a summary, these Web APIs are fast on the slow, not common, use case (huge strings) and slow on the fast path for common use cases (mixed data serialization, keys, names, surnames, addresses and so on …) can we please think about doing the other way around or do something new that’s native fast for the 90% of scenarios? I really do hope so, thank you!

[annevk]

You need to work on presenting your claims more clearly as this is not actionable as-is. It seems likely that certain scenarios are not optimized and it also seems plausible that a native implementation can beat a non-optimized C++ implementation, but having read this issue a few times it's not clear what specific scenarios are problematic and what benchmarks proof the claims that are made.

An alternative route you could pursue is to make this API part of an existing benchmark, forcing implementations to optimize it.

[WebReflection]

all benchmarks were provided via projects listed in the source of this issue: #333 (comment)

the codepen shows that native APIs are 2 up to 3X slower than cbor-x implementation but admittedly that's not super clear in the code or as pen ... should I provide an easier to read/reason about benchmark?

[annevk]

Those links are indeed useful. Why did you decide to not use them for OP? In particular https://www.appspector.com/blog/how-to-improve-messagepack-javascript-parsing-speed-by-2-6-times shows in a pretty straightforward manner that user agents should probably attempt to optimize for shorter inputs as they are not competitive there.

[WebReflection]

Why did you decide to not use them for OP?

I naively believed linking that comment in the OP would've been enough ... my bad