この投稿では、パフォーマンスが予想よりもはるかに低いコードを記述しない方法に関するヒントを提供します。 これは、V8エンジン（Node.js、Opera、Chromiumなどで使用）が一部の機能の最適化を拒否する場合に特に当てはまります。

V8の機能

このエンジンにはインタープリターはありませんが、通常と最適化の2つの異なるコンパイラーがあります。 つまり、JSコードは常にネイティブとして直接コンパイルおよび実行されます。 高速だと思う？ あなたは間違っています。 ネイティブコードにコンパイルしても、実際にはパフォーマンスは向上しません。 インタプリタの使用を取り除くだけですが、最適化されていないコードの動作は遅くなります。

たとえば、通常のコンパイラでは、式a + bは次のようになります。

mov eax, a mov ebx, b call RuntimeAdd 

これは、対応する関数の呼び出しです。 aとbが整数の場合、コードは次のようになります。

 mov eax, a mov ebx, b add eax, ebx 

また、このオプションは、実行時に複雑な追加のJSセマンティクスを処理する呼び出しよりもはるかに高速に機能します。 言い換えれば、通常のコンパイラは最適化されていない「生の」コードを生成し、最適化コンパイラはそれを思い起こさせて、最終的な外観に導きます。 同時に、最適化されたコードのパフォーマンスは、「通常の」コードのパフォーマンスの100倍になります。 しかし、実際には、JSコードを記述して最適化することはできません。 最適化コンパイラが処理を拒否する多くのプログラミングパターンがあります（その一部は慣用的です）。

テンプレートが最適化されていない場合、テンプレートを含む関数全体に影響することに注意してください。 結局、コードは一度に1つの関数で最適化され、システムは残りのコードが何を行うかを知りません（現時点で最適化されている関数に組み込まれていない限り）。

以下では、その機能が「最適化解除の地獄」に分類されるほとんどのテンプレートを見ていきます。 ほとんどの場合、それらを変更することは理にかなっており、コンパイラーがますます新しいテンプレートを認識するようになると、提案されたソリューションが不要になる可能性があります。

1.組み込みツールの使用

テンプレートが最適化にどのように影響するかを判断するには、Node.jsをいくつかのV8フラグとともに使用できる必要があります。 特定のテンプレートを使用して関数を作成し、すべての種類のデータ型で関数を呼び出してから、内部V8関数を呼び出してチェックと最適化を行います。

test.js：

 // Function that contains the pattern to be inspected (using with statement) function containsWith() { return 3; with({}) {} } function printStatus(fn) { switch(%GetOptimizationStatus(fn)) { case 1: console.log("Function is optimized"); break; case 2: console.log("Function is not optimized"); break; case 3: console.log("Function is always optimized"); break; case 4: console.log("Function is never optimized"); break; case 6: console.log("Function is maybe deoptimized"); break; case 7: console.log("Function is optimized by TurboFan"); break; default: console.log("Unknown optimization status"); break; } } // Fill type-info containsWith(); // 2 calls are needed to go from uninitialized -> pre-monomorphic -> monomorphic containsWith(); %OptimizeFunctionOnNextCall(containsWith); // The next call containsWith(); // Check printStatus(containsWith); 

打ち上げ：

 $ node --trace_opt --trace_deopt --allow-natives-syntax test.js Function is not optimized 

機能をテストするには、withステートメントをコメント化して再起動します。

 $ node --trace_opt --trace_deopt --allow-natives-syntax test.js [optimizing 000003FFCBF74231 <JS Function containsWith (SharedFunctionInfo 00000000FE1389E1)> - took 0.345, 0.042, 0.010 ms] Function is optimized 

選択したソリューションが機能するかどうかを確認するには、組み込みのツールキットを使用することが重要です。

2.サポートされていない構文

一部の構造は、最適化できない構文を使用するため、最適化コンパイラによって明示的にサポートされません。

重要：デザインが利用できない場合や実行されない場合でも、デザインを含む関数を最適化することはできません。

たとえば、これを行うのは無意味です。

 if (DEVELOPMENT) { debugger; } 

このコードは、デバッガー式の実行に失敗しても、関数全体に影響します。

現在最適化されていません：

• ジェネレーター関数;
• for-of式を含む関数。
• try-catch式を含む関数。
• try-finally式を含む関数。
• 複合代入演算子letを含む関数。
• const代入演算子constを含む関数。
• オブジェクトリテラルを含む関数には、__ proto __、get、またはset宣言が含まれます。

おそらく、最適化できない：

• デバッガー式を含む関数。
• eval（）を呼び出す関数;
• 式を含む関数。

誤解を避けるために、関数に次のいずれかが含まれている場合、その全体は最適化されません。

 function containsObjectLiteralWithProto() { return {__proto__: 3}; } function containsObjectLiteralWithGetter() { return { get prop() { return 3; } }; } function containsObjectLiteralWithSetter() { return { set prop(val) { this.val = val; } }; } 

evalへの直接の呼び出しは、特に言及するに値します。なぜなら、それらが動作するものはすべて動的スコープ内にあるためです。

回避策 ：これらの式の一部は、完成した製品コードでは破棄できません。 たとえば、try-finallyまたはtry-catchから。 有害な影響を最小限に抑えるには、小さな機能のフレームワークでそれらを分離する必要があります。

 var errorObject = {value: null}; function tryCatch(fn, ctx, args) { try { return fn.apply(ctx, args); } catch(e) { errorObject.value = e; return errorObject; } } var result = tryCatch(mightThrow, void 0, [1,2,3]); // Unambiguously tells whether the call threw if(result === errorObject) { var error = errorObject.value; } else { // Result is the returned value } 

3.引数を使用する

関数を最適化することが不可能になるように、引数を使用する多くの方法があります。 したがって、引数を操作するときは、特に注意する必要があります。

3.1。 引数が関数本体で使用されるという条件で、指定されたパラメーターの再割り当て（不安定モード（スロッピーモード）のみ）

典型的な例：

 function defaultArgsReassign(a, b) { if (arguments.length < 2) b = 5; } 

この場合、パラメーターを新しい変数に保存できます。

 function reAssignParam(a, b_) { var b = b_; // Unlike b_, b can safely be reassigned if (arguments.length < 2) b = 5; } 

これが関数で引数を使用する唯一の方法である場合、undefinedでチェックすることで置き換えることができます。

 function reAssignParam(a, b) { if (b === void 0) b = 5; } 

引数が関数の後半で使用される可能性が高い場合、再割り当てを心配する必要はありません。

問題を解決する別の方法は、ファイルまたは関数に対して「厳密な使用」を有効にすることです。

3.2。 漏えいした議論

 function leaksArguments1() { return arguments; } function leaksArguments2() { var args = [].slice.call(arguments); } function leaksArguments3() { var a = arguments; return function() { return a; }; } 

引数オブジェクトはどこにも渡してはいけません。

プロキシは、内部配列を作成することで実行できます。

 function doesntLeakArguments() { // .length is just an integer, this doesn't leak // the arguments object itself var args = new Array(arguments.length); for(var i = 0; i < args.length; ++i) { // i is always valid index in the arguments object args[i] = arguments[i]; } return args; } 

この場合、多くのコードを作成する必要があるため、最初にゲームがろうそくに値するかどうかを判断するのが理にかなっています。 繰り返しますが、最適化には大量のコードが含まれ、より明確なセマンティクスが伴います。

ただし、プロジェクトがアセンブリ段階にある場合は、ソースマップを使用する必要のないマクロを使用してこれを実現でき、通常のJavaScriptとしてソースコードを保存できます。

 function doesntLeakArguments() { INLINE_SLICE(args, arguments); return args; } 

この手法はbluebirdで使用され、ビルド段階でコードは次のようになります。

 function doesntLeakArguments() { var $_len = arguments.length;var args = new Array($_len); for(var $_i = 0; $_i < $_len; ++$_i) {args[$_i] = arguments[$_i];} return args; } 

3.3。 引数への割り当て

これは、不安定モードでのみ実行できます。

 function assignToArguments() { arguments = 3; return arguments; } 

解決策 ：そのようなばかげたコードを書かないでください。 厳格モードでは、そのような創造性は排除につながります。

引数を安全に使用するにはどうすればよいですか？

• arguments.lengthを使用します。
• 引数[i]を使用します。ここで、iは常に引数内の有効な整数インデックスであり、その境界外にあることはできません。
• .lengthまたは[i]なしで引数を直接使用しないでください。
• strictモードでfn.apply（y、引数）を適用できます。 そして、特に.slice。 機能番号が適用されます。
• 関数（たとえば、fn。$ Inject = ...）および制限された関数（たとえば、Function＃bindの結果）にプロパティを追加すると、隠しクラスが作成されることに注意してください。したがって、これは#applyを使用する場合は安全ではありません。

上記のすべてを確認した場合、引数を使用してもこのオブジェクトのメモリは割り当てられません。

4.スイッチケース

現在、switch-case式は最大128個のケースポイントを持つことができ、この数を超えると、この式を含む関数を最適化できません。

 function over128Cases(c) { switch(c) { case 1: break; case 2: break; case 3: break; ... case 128: break; case 129: break; } } 

関数の配列またはif-elseを使用して、128以内のケース数を保持します。

5. For-in

For-in式は、いくつかの方法で関数の最適化を妨げる可能性があります。

5.1。 キーはローカル変数ではありません

 function nonLocalKey1() { var obj = {} for(var key in obj); return function() { return key; }; } var key; function nonLocalKey2() { var obj = {} for(key in obj); } 

キーを上位のスコープから取得したり、下位のスコープを参照したりすることはできません。 排他的にローカル変数にする必要があります。

5.2。 iterableは「単純な列挙可能」ではありません

5.2.1。 「ハッシュテーブル」モードのオブジェクト（「正規化オブジェクト」、「辞書」-補助データ構造がハッシュテーブルであるオブジェクト）は単純な列挙型ではありません

 function hashTableIteration() { var hashTable = {"-": 3}; for(var key in hashTable); } 

たとえば、オブジェクトをハッシュテーブルモードにすることができます。たとえば、コンストラクター外でプロパティを動的に追加しすぎたり、プロパティを削除したり、有効な識別子ではないプロパティを使用したりした場合などです。つまり、このようなオブジェクトを使用すると、ハッシュテーブルであるかのように、ハッシュテーブルに変わります。 そのようなオブジェクトをfor-inに渡してはいけません。 オブジェクトがハッシュテーブルモードであるかどうかを確認するには、Node.jsで--allow-natives-syntaxフラグをアクティブにしてconsole.log（％HasFastProperties（obj））を呼び出すことができます。

5.2.2。 オブジェクトプロトタイプチェーンに列挙値を持つフィールドがあります

 Object.prototype.fn = function() {}; 

この文字列は、列挙プロパティにすべてのオブジェクトのプロトタイプのチェーンを提供します（Object.create（null）を除く）。 したがって、for-in式を含む関数は、Object.create（null）オブジェクトを列挙しない限り、最適化できなくなります。

Object.definePropertyを使用すると、列挙不可能なプロパティを割り当てることができます。 実行時にこれを行うことはお勧めしません。 しかし、プロトタイプのプロパティのような静的なものを効果的に決定するために-それだけです。

5.2.3。 オブジェクトには列挙された配列インデックスが含まれます。

配列インデックスのプロパティはECMAScript仕様で定義されていると言わなければなりません：

プロパティの名前（文字列）は、ToString（ToUint32（P））がPと等しく、ToUint32（P）が2 ^32-1でない場合にのみ、配列のインデックスになります。名前が配列のインデックスであるプロパティは、要素とも呼ばれます。

これは通常配列に適用されますが、通常のオブジェクトは配列インデックスを持つこともできます。

 normalObj[0] = value; function iteratesOverArray() { var arr = [1, 2, 3]; for (var index in arr) { } } 

for-inを使用した配列の反復はforを使用するよりも遅く、for-inを含む関数は最適化されません。

for-inに単純な列挙型ではないオブジェクトを渡すと、関数に悪影響を及ぼします。

解決策 ：常にObject.keysを使用し、forループを使用して配列を反復処理します。 プロトタイプチェーンのすべてのプロパティが本当に必要な場合は、独立したヘルパー関数を作成します。

 function inheritedKeys(obj) { var ret = []; for(var key in obj) { ret.push(key); } return ret; } 

6.終了条件の複雑なロジックまたは終了条件が不明確な無限ループ

コードを記述するときに、ループを作成する必要があることを理解していても、ループに何を入れるべきかわからない場合があります。 それから、while（true）{またはfor（;;）{を入力し、ループにブレークを挿入します。 リファクタリングの時が来るのは、関数の実行が遅いこと、または一般的に最適化が解除されていることが判明したときです。 理由は、忘れられた中断状態である可能性があります。

ループ式の条件部分に終了条件を配置するためにループをリファクタリングすることは簡単ではありません。 条件がループの最後のifステートメントの一部であり、コードを少なくとも1回実行する必要がある場合は、ループをリファクタリングして{} while（）;を実行します。 終了条件が先頭にある場合は、ループ本体の条件部分に配置します。 終了条件が中央にある場合は、コードをいじることができます。コードの一部を上の行から下に移動するたびに、ループの上の行のコピーを残します。 条件付きテストまたは少なくとも単純な論理テストを使用して終了条件を確認できた後、ループは最適化解除されなくなります。