You could try speedup this a little use -O3 flag instead --optimize (which -O2s actually). But I guess main reason why wasm version slower is interop overhead which could significant if your wasm function called quite frequently.

You could try this approach:

const threshold = 100; // adjust this
function utf8ToUtf16String(bytes: Uint8Array) {
 if (bytes.length > threshold) {
 return wasmUtf8ToUtf16(...)
 } else {
 return jsUtf8ToUtf16(...)
 }
}

@MaxGraey Thanks for your advice!

As I attached my benchmark script to the description, I am using a large target string like "Hello, 🌏\n".repeat(1000). Even though such a situation with -O3, AssemblyScript version much slower than JS:

$ npm run asbuild && USE_WASM=true npx ts-node benchmark/string.ts
> @msgpack/msgpack@1.0.1 asbuild /Users/gfx/.ghq/github.com/msgpack/msgpack-javascript
> npm run asbuild:untouched && npm run asbuild:optimized
> @msgpack/msgpack@1.0.1 asbuild:untouched /Users/gfx/.ghq/github.com/msgpack/msgpack-javascript
> asc assembly/index.ts -b build/wasm/untouched.wasm -t build/wasm/untouched.wat --sourceMap --validate --debug
> @msgpack/msgpack@1.0.1 asbuild:optimized /Users/gfx/.ghq/github.com/msgpack/msgpack-javascript
> asc assembly/index.ts -b build/wasm/optimized.wasm -t build/wasm/optimized.wat --sourceMap --validate -O3
encode: 1666.293ms
decode: 4684.249ms
$ npx ts-node benchmark/string.ts
encode: 1622.107ms
decode: 1234.643ms

(only decode() uses AssemblyScript ver.)

My environment: NodeJS v12.2.0 on macOS 10.14.4 (Mojave)

Do you have any idea?

Try to decrease iteration count from 1000 to 10-20 and increase input string size (repeat argument) from 1000 to 5000 and see will it change something

Tried:

diff --git a/benchmark/string.ts b/benchmark/string.ts
index ebf0314..b47613d 100644
--- a/benchmark/string.ts
+++ b/benchmark/string.ts
@@ -1,6 +1,6 @@
 import { encode, decode } from "../src";
 
-const data = "Hello, 🌏\n".repeat(1000);
+const data = "Hello, 🌏\n".repeat(10_000);
 
 // warm up
 const encoded = encode(data);
@@ -9,13 +9,13 @@ decode(encoded);
 // run
 
 console.time("encode");
-for (let i = 0; i < 10000; i++) {
+for (let i = 0; i < 1000; i++) {
 encode(data);
 }
 console.timeEnd("encode");
 
 console.time("decode");
-for (let i = 0; i < 10000; i++) {
+for (let i = 0; i < 1000; i++) {
 decode(encoded);
 }
 console.timeEnd("decode");

But little changes:

$ USE_WASM=true npx ts-node benchmark/string.ts
encode: 1557.384ms
decode: 6345.717ms
$ npx ts-node benchmark/string.ts
encode: 1565.238ms
decode: 2784.192ms

Note: repeat(100_000) causes Maximum call stack size exceeded error.

Note: repeat(100_000) causes Maximum call stack size exceeded error.

Try to avoid using String.fromCharCode(...utf16array) it slow and cause to SO when size of array >= 64k.

I think if you decrease 1000 -> 10. AS should be the same speed as JS or faster. As I mentioned before you have JS <-> WASM interop overhead, which is good know performance issue for WebAssembly especially for v8 vm

Hmm? As far as I know, String.fromCharCode(...utf16array) is the only way to create strings from ArrayBuffer or an array of codepoints. I'd like to know some other faster way if exists.

Right, but better use String.fromCharCode.apply with fixed chunk size like in here

Interesting! I thought there's no difference on String.fromCharCode(...arrayLike) and String.fromCharCode.apply(String, arrayLike) and it is true if the arrayLike is the actual Array and the JS engine supports ES2015, but #apply is much faster if the arrayLike is a typed array.

Now WASM ver. is faster than JS ver. for a large string! dfe06c3

$ USE_WASM=true npx ts-node benchmark/string.ts
encode: 1547.967ms
decode: 1625.489ms
$ USE_WASM=false npx ts-node benchmark/string.ts
encode: 1526.350ms
decode: 2743.125ms

Now WASM ver. is a little bit faster than JS ver.

now wasm faster on ~60%. It's pretty good result. In comparison with JS 1.5-3x speedup usually achieved

Yep! not "a little bit", but 1.5x faster. Sounds great enough to proceed to merge this PR.

@MaxGraey

I've implemented utf8EncodeWasm() in AssemblyScript, but its performance is almost the same as pure JS ver., whilet the decode-in-wasm function is about 1.5x faster than JS ver. (NodeJS/v12.3.1 on macOS):

$ WASM=never npx ts-node benchmark/string.ts && echo && WASM=force npx ts-node benchmark/string.ts
WASM_AVAILABLE=false
encode / decode ascii data.length=40000 encoded.byteLength=40003
encode ascii: 542.870ms
decode ascii: 868.292ms
encode / decode emoji data.length=40000 encoded.byteLength=80005
encode emoji: 653.479ms
decode emoji: 892.014ms
WASM_AVAILABLE=true
encode / decode ascii data.length=40000 encoded.byteLength=40003
encode ascii: 528.937ms
decode ascii: 520.596ms
encode / decode emoji data.length=40000 encoded.byteLength=80005
encode emoji: 555.948ms
decode emoji: 595.192ms

I think the overhead of preparation that converts string to an array of utf16 units (i.e. setMemoryStr() in wasmFunctions.ts) is too heavy, but I have no idea to get it better.

Do you have any idea about it?

Definitely you have interop overhead. Hard to tell how this improve. Try eliminate calls between JS and wasm. For example: use one shared buffer (with max size of both) for input and output and use inplace process if this possible

Hmm! Will give it a try to reduce some js<->wasm calls.

Thank you for your advice, anyway! I'll merge this PR in a few days and will send feedbacks to AssemblyScript.

@gfx Sure! It will be great