Bluebirdを高速化する3つのJavaScriptパフォーマンス原則

Reaktorは、ブログで、従業員Petka Antonov（Petka Antonov）によって作成されたBluebird Promisesライブラリで使用されるJavaScriptコード最適化の原則と例を共有しました。

Bluebirdは、人気のあるJavaScript Promiseライブラリです。 2013年に最初に気づかれたのは、同様のプロパティセットを備えた他のPromises実装を最大100倍上回ることが判明したときです。 JavaScriptの基本的な最適化原則のいくつかを一貫して適用しているため、Bluebirdは非常に高速です。 この記事では、Bluebirdの最適化に使用される3つの最も重要な原則について詳しく説明します。

1.機能の作成を最小限に抑える

オブジェクトの作成、特に関数オブジェクトの作成（ 翻訳者注： すべての関数はオブジェクトです ） は、大量の内部データを使用する必要があるため、パフォーマンスの点で非常にコストがかかります。 実際のJavaScript実装にはガベージコレクターが含まれています。つまり、作成されたオブジェクトはメモリ内に留まることはありません。ガベージコレクターは未使用のオブジェクトを常に検索して、占有しているメモリを解放します。 JavaScriptで使用するメモリが多いほど、ガベージコレクションにかかるCPUが多くなり、コード自体が機能するために残される量が少なくなります。 JavaScriptでは、関数はファーストクラスオブジェクトです 。 これは、他のオブジェクトと同じ機能とプロパティを持っていることを意味します。 別の関数の宣言を含む関数がある場合、元の関数を呼び出すたびに、同じことを行う新しい一意の関数が作成されます。 簡単な例を考えてみましょう。

function trim(string) { function trimStart(string) { return string.replace(/^\s+/g, ""); } function trimEnd(string) { return string.replace(/\s+$/g, ""); } return trimEnd(trimStart(string)) } 

trimが呼び出されるたびに、 trimStartとtrimEndを表す2つの関数オブジェクトが作成されます。 ただし、プロパティの割り当てなどのオブジェクト固有の動作や変数の閉包を使用しないため、これらは必要ありません。 それらが使用される唯一の理由は、含まれるコードの機能のためです。

この例は簡単に最適化できます-関数をtrimから取り出すだけです。 この例はモジュールに含まれており、モジュールはプログラムに一度ロードされるため、関数の場合、表現は1つだけです。

 function trimStart(string) { return string.replace(/^\s+/g, ""); } function trimEnd(string) { return string.replace(/\s+$/g, ""); } function trim(string) { return trimEnd(trimStart(string)) } 

ただし、ほとんどの場合、機能は必要な悪のように見えますが、それを取り除くことはできません。 たとえば、遅延コールのコールバック関数を渡すたびに、コールバックには一意のコンテキストが必要です。 通常、コンテキストは、クロージャーを使用することにより、シンプルで直感的ですが非効率的な方法で実装されます。 簡単な例として、標準の非同期コールバックインターフェイスを使用して、JSONからノードにファイルを読み取ります。

 var fs = require('fs'); function readFileAsJson(fileName, callback) { fs.readFile(fileName, 'utf8', function(error, result) { //        readFileAsJson. //   ,    Context //   . if (error) { return callback(error); } //  try-catch    //    -  JSON try { var json = JSON.parse(result); callback(null, json); } catch (e) { callback(e); } }) } 

この例では、 fs.readFile渡されたコールバックは、一意のcallback変数の周りにクロージャーを作成するため、 readFileAsJsonからfs.readFileことができません。 名前付き関数に匿名のコールバックを試みても何も起こらないことに注意してください。

Bluebird内で常に使用される最適化は、明示的な単純なオブジェクトを使用してコンテキストデータを保持することです。 多くのレベルでコールバックを転送するには、そのようなオブジェクトの1つだけにメモリを割り当てる必要があります。 各レベルで新しいクロージャーを作成する代わりに、コールバックが次のレベルに渡されるときに、追加の引数を使用して明示的な単純なオブジェクトを渡します。 たとえば、元の関数に5つのレベルがある場合、クロージャーを使用すると、5つの関数とContextオブジェクトがそれらと共に作成されることを意味します。 この最適化の場合、これらの目的のために1つのオブジェクトのみが作成されます。

fs.readFileを変更してコンテキストオブジェクトを渡すことができる場合、最適化は次のように適用できます。

 var fs = require('fs-modified'); function internalReadFileCallback(error, result) { //  readFile  callback    , //   `this`, //         if (error) { return this(error); } //  try-catch    //    -  JSON try { var json = JSON.parse(result); this(null, json); } catch (e) { this(e); } } function readFileAsJson(fileName, callback) { //  fs.readFile     . //     ,    callback, //          fs.readFile(fileName, 'utf8', internalReadFileCallback, callback); } 

もちろん、APIの両方の部分を制御する必要があります-コンテキストパラメーターのサポートなしでは、このような最適化は適用できません。 ただし、それを使用する場合（たとえば、多くの内部レベルを制御する場合）、パフォーマンスの向上は顕著です。 あまり知られていない事実： Array.prototype.forEachなどの一部の組み込みJavaScript Array APIは、2番目のパラメーターとしてコンテキストオブジェクトをArray.prototype.forEachます。

2.オブジェクトのサイズを最小化します

頻繁に作成されるオブジェクトと、Promiseなどの大量に作成されるオブジェクトのサイズを最小限に抑えることが重要です。 ほとんどのJavaScript実装でオブジェクトが作成されるヒープは、占有領域と空き領域に分けられます。 小さいオブジェクトは大きいオブジェクトよりも長く空きスペースを埋め、その結果、ガベージコレクターの作業が少なくなります。 また、通常、小さなオブジェクトには含まれるフィールドが少ないので、ガベージコレクターはそれらの周りを簡単に移動して、ライブオブジェクトとデッドオブジェクトをマークします。

ブールおよび/または制限された数のフィールドは、 ビット単位の操作によってさらに圧縮されます 。 JavaScriptのビット演算は、32ビットの数値で機能します。 1つのフィールドには、32個のブールフィールド、8個の4ビット数、16個のブール値と2個の8ビット数などを配置できます。コードを読みやすくするには、各論理フィールドに必要なビット演算を実行するゲッターとセッターが必要です物理的な意味。 1つのブール型フィールドを数値に圧縮する方法の例を次に示します（他の論理フィールド用にさらに展開できます）。

 //  1 << 1   , 1 << 2    .. const READONLY = 1 << 0; class File { constructor() { this._bitField = 0; } isReadOnly() { //  . return (this._bitField & READONLY) !== 0; } setReadOnly() { this._bitField = this._bitField | READONLY; } unsetReadOnly() { this._bitField = this._bitField & (~READONLY); } } 

アクセスメソッドは非常に短いので、ほとんどの場合、追加の関数呼び出しなしでランタイムに組み込まれます。

翻訳者のメモ： JavaScriptコンパイラーの操作に関する基本情報、インラインキャッシングと埋め込み関数の概念については、記事「 JavaScriptコンパイルの過去と未来」を参照してください。 オプティマイザーの動作について-Petka Antonovによる最適化キラー （オリジナルの更新もあります）およびOptimization Killerの翻訳（2014年に公開）。

同時に使用されない2つ以上のフィールドは、フィールドに配置された値のタイプを追跡するフラグを使用して1つのフィールドに圧縮できます。 ただし、上記のように、フラグが圧縮された数値として実装されている場合にのみ、このメソッドはスペースを節約します。

Bluebirdでは、このトリックを使用して、約束の価値または拒否の理由を保持します。 これには別のフィールドはありません。約束が満たされた場合、実行の結果は拒否コールバックのフィールドに格納され、約束が拒否された場合、拒否の理由は成功応答コールバックフィールドに保存されます。 繰り返しますが、値へのアクセスは、実装の詳細を隠すアクセス関数を介して行う必要があります。

オブジェクトにエンティティのリストを保存する必要がある場合は、オブジェクトのインデックス付きプロパティに値を直接保存することにより、個別の配列の作成を回避できます。 書く代わりに：

 class EventEmitter { constructor() { this.listeners = []; } addListener(fn) { this.listeners.push(fn); } } 

配列を避けることができます：

 class EventEmitter { constructor() { this.length = 0; } addListener(fn) { var index = this.length; this.length++; this[index] = fn; } } 

.lengthフィールドを小さな数に制限できる場合（たとえば、10ビット、つまり、 event emitterは最大1024人のリスナーを持つことができます）、他の制限された数とブール値を含むビットフィールドの一部にすることができます。

3. no-op関数を使用します。 高価なオプション機能を実装するためにそれらを遅延的に書き換えます

Bluebirdには、使用時にライブラリ全体のパフォーマンスを均一に低下させるいくつかのオプション機能が含まれています。 これらは、vorings、スタックトレース、キャンセルする機能、Promise.prototype.bind、promiseのステータスの監視などです。 これらの関数には、ライブラリ全体でインターセプター呼び出しが必要です。 たとえば、Promise監視機能では、Promiseを作成するたびにインターセプターを呼び出す必要があります。

実際の状態に関係なく、毎回監視機能を起動するよりも、監視機能がオンになっているかどうかを呼び出す前に確認する方がはるかに簡単です。 ただし、インラインキャッシュ（ 翻訳者のメモ：トピックに関する別のメモ ）と機能の統合のおかげで、この操作は監視を無効にしているユーザーに対して完全に簡素化できます。 これを行うには、空の関数を元のインターセプターメソッドに割り当てます。

 class Promise { // ... constructor(executor) { // ... this._promiseCreatedHook(); } //   no-op . _promiseCreatedHook() {} } 

現在、ユーザーが監視機能を有効にしていない場合、オプティマイザーはインターセプターが何もしていないことを確認し、それを簡素化します。 コンストラクターにインターセプターメソッドが存在しないことがわかります。

監視機能が機能するためには、監視機能を含めると、関連するすべてのno-op機能が実際の実装に上書きされます。

 function enableMonitoringFeature() { Promise.prototype._promiseCreatedHook = function() { //   }; // ... } 

このようなメソッドの書き換えにより、Promiseクラスのオブジェクト用に作成されたインラインキャッシュが無効になります。 これは、約束が作成される前に、アプリケーションの起動時に行う必要があります。 したがって、この後に作成されたインラインキャッシュは、no-op関数が存在したことを認識しません。

オリジナル：Petka AntonovによるBluebirdを高速にする3つのJavaScriptパフォーマンスの基礎 。

翻訳： aalexeev 、 改訂者 ： jabher 。