本記事は「Node.jsのworker_threadsに使えるバイナリフォーマットを考えた件」のスピンオフ作品となっております。

1. お題目

「Node.jsのworker_threadsに使えるバイナリフォーマットを考えた件」では、worker_threadを使った親子スレッド間でデータを共有するにはSharedArrayBuffer(MDN)を使うことを知りました。
SharedArrayBufferはバイナリ配列ですから、JavaScriptの数値、文字列、オブジェクト、配列等々のデータは直接格納できません。そのため、ここに格納するためのシリアライザ、取り出すためのデシリアライザを検討しました。

わざわざ考えなくても似たようなものはあるのですが、いまいち目的に足りてないことがあって自分で作ってみた、という話なんですが、処理性能という面ではどうしても既存のものに勝てません。

そう、その者の名はJSON。

まあしょうがないんですよ。相手はネイティブコードで動いてますからね（多分）。目的もできることも違いますし。
にしてもちょっとでも差を縮めたいというのが親心というもの。

で、今回は、文字列のシリアライズ処理に目を付けて性能改善を図ってみた（図ろうとしてみた）という話になります。

2. 文字列シリアライズの方法いろいろ

本記事で「文字列シリアライズ」と言っているのは、Stringをバイナリ配列化すること、もっと具体的に言うと(Shared)ArrayBufferに格納すること、とします。その逆をデシリアライズとします。

(1) 自前(DataView使用)

DataView(MDN)は、(Shared)ArrayBufferを扱うためのViewの一つです。
JavaScriptのStringは、charCodeAt()を使ってUTF-16のコードを取り出すことができるので、UTF-16で良いならそのコードを一文字ずつArrayBufferにDataView.setUint16()関数で書き込んでいきます。
That's Simple!
ざっくり書くと

constbuf=newArrayBuffer(str.length*2);constdataView=newDataView(buf);for(letci=0;ci<strLen;ci++){dataView.setUint16(ci*2,str.charCodeAt(ci),true/*UTF16LE*/);}

こんな感じで使います。

UTF-8が良いならばサロゲートペアのことも考えて、codePointAt()で取り出してその値をごにょごにょした後、1byteずつDataView.setUint8()で書き込んでいく感じになろうかと思います。

デシリアライズはその逆ですが、一文字ずつ取り出されるので、str += String.fromCharCode(code);みたいな感じで結合していきます。

constdataView=newDataView(buf);letdecodedStr="";for(letci=0;ci<strLen;ci++){decodedStr+=String.fromCharCode(dataView.getUint16(ci*2,true));}

(2) TextEncoder/TextDecoder

TextEncoder/TextDecorder(MDN)は最近のブラウザならどれでも使えます。もちろんChromeと同じエンジンであるNode.jsでも使えます。
なんか字面見ると普通にこれ使えばいいじゃんて感じしますよね。
まあ、後半のベンチマークをお楽しみってことで。
先に少しネタばらしすると、TextEncoderさんはUTF-8でしかエンコードをしてくれないので変換処理がはさまる関係上UTF-16より不利になりがちです。
なぜかTextDecoderはUTF-16にも対応している謎の仕様・・・。

// シリアライズ(encodeを使用)constbuf=newArrayBuffer(str.length*3);constuint8view=newUint8Array(buf);constencoder=newTextEncoder();constencoded=encoder.encode(str);uint8view.set(encoded);// UTF-8は元の文字列長からbyte数を直接計算できないので読み込み時のために書き込みbyte数を保持しておく constencodedBytes=encoded.length;// シリアライズ(encodeIntoを使用)constbuf=newArrayBuffer(str.length*3);constencoder=newTextEncoder();constencodeView=newUint8Array(buf);constencodeResult=encoder.encodeInto(str,encodeView);constencodedBytes=encodeResult.written;// デシリアライズconstdecoder=newTextDecoder();constdecodeView=newUint8Array(buf,0,encodedBytes);constdecodedStr=decoder.decode(decodeView);

(3) Buffer

Buffer(Node.js公式)はNode.js独自のAPIです。
Buffer.from(String)や、Buffer.write(String)なんかを使ってシリアライズしていきます。
デシリアライズはBuffer.toString()になります。
基本的に優秀なんですが、Node.jsでしか使えないのが玉にきず。

// シリアライズ(Buffer.fromを使用)constbuf=newArrayBuffer(str.length*2);constuint8view=newUint8Array(buf);constencoded=Buffer.from(str,encode);uint8view.set(encoded);// シリアライズ(Buffer.writeを使用)constbuf=newArrayBuffer(strLen*2*repeat);constnodeBufferView=Buffer.from(buf);nodeBufferView.write(str,"utf16le");// デシリアライズconstdecodeBufferView=Buffer.from(buf);constdecodedStr=decodeBufferView.toString('utf16le');

3. ベンチマーク

環境はこんな感じ（しょぼいです・・・）。
- OS: Windows10(1909)
- CPU: Core i3-3120M
- メモリ: 4GB
- Node.js: v12.16.0

処理条件はこんな感じ。
- 1億文字（UTF-16換算で200Mbyte）のStringをArrayBufferに書き込む、読み出す。
- ただし、1億文字を「一つの文字列として一気に書き込む」～「10文字ずつ1000万回書き込む」のバリエーションで検証。読み出す（デシリアライズする）方も同様。
- 繰り返し書き込むパターンの場合、1度で済む処理はループの外でやる。例えばTextEncoderTextDecoderなんてのは一度newしとけばいいのでループの前でやる。
- 5回計測してその平均を取る。

ソース(Gist)

(1) シリアライズ結果

（単位はms）

どうでしょうか。書き込み回数が少ない（＝一度の書き込みbyte数が多い）時にはBuffer.write(utf16le)無双状態ですが、一度に200byte（100万回書き込み）あたりから効率が悪化し、20byteずつになると目も当てられなくなってきます。
UTF-8一族はやはり遅い。ごにょごにょする分どうしても遅くなるのだと思われます。TextEncoder.encodeIntoは惜しいところまでは行ってますがBufferにはかないません。ただ、Bufferがブラウザにないことを考えるとencodeIntoを使ってもいいかもしれません。
DataView.setUint16は書き込み回数に関係なく一定の処理時間になりました。考えてみれば書き込み回数分のループと、文字列長のループの二重ループで回していますが、中と外のループの比率が違うだけで、ループの中の処理（charCodeAt()とsetUint16()）は同じ回数動いてるので変わらないはずです。

(2) デシリアライズ結果

（単位はms）

ここでも「Buffer優位」「UTF-16優位」「読み込み回数増で効率悪化」の傾向は同じですが、UTF-8に関してはTextDecoderがBufferを凌駕してますね。どうしたんでしょう。
DataViewはシリアライズと違ってずいぶんと不安定な結果になりました。1回読み込みはエラーが出てしまい計測できませんでした。
これは、文字列に一文字ずつ文字を足しては新しい文字列を作ってるからで、（それでも結構速いんだよって記事をどっかで見ましたが・・・）さすがに1億回の結合には耐えられなかったようです。例えば1000文字ずつ結合した配列に入れておいて、最後にまとめてjoinみたいなやり方にすれば回避はできるかもしれませんが、どちらにせよそれほど効率は良くないですね。
ただ、1000万回の時はTextDecoderより速くなってます。

4. さあ教えたまえ！失敗しない文字列シリアライザとやらを！

そんなものは最初からなかったんだ・・・。

決定版！はないわけですが、以下のような条件を考慮して使い分けになるのかなあと思います。
- シリアライズ結果のサイズより速度重視ならUTF-16を使う。¹
- Bufferが使えるとき（つまりNodeの時）はBufferを使う。
- ただし、小さい文字列を扱う時はシリアライズはDataView、デシリアライズはBufferかDataViewを使う。

5. で

roJson高速化を目指してベンチマーク取ってみたわけですが、roJsonは小さい文字列（主にkeyですね・・・）を相手にするのでDataViewが無難。もともとDataViewで作ってたので結果変わらず！ということになりました。残念。。。