おそらく、JavaScriptはソフトウェア開発で最も重要な最新テクノロジーであると言っても十分でしょう。プログラミング言語、コンパイラー、および仮想マシンを研究した多くの人々にとって、JavaScript言語の構造という点でその優雅さがすべてコンパイルに関してまだ十分に最適化されておらず、素晴らしい標準ライブラリを誇ることができないという事実は依然として驚くべきことです。対話者が誰であるかに応じて、JavaScriptの欠陥を数週間にわたってリストしても、聞いたことがないような奇妙なものを見つけることができます。しかし、明らかな欠陥にもかかわらず、今日、JavaScriptはWebの重要な技術であり、サーバー/クラウド領域での優位性に向かっています（Node.jsのおかげです）。また、モノのインターネットにも浸透しています。

質問は-なぜJavaScriptはそんなに人気があるのですか？包括的な答えがないのではないかと心配しています。今日、この言語を使用する多くの理由がありますが、最も重要なのはおそらく、JavaScriptと無数のリソースを中心に構築された巨大なエコシステムです。しかし、これはすべてある程度の結果です。そして、なぜこの言語は最初に普及したのですか？あなたは言うことができます：なぜなら彼は長い間、ウェブの共通語だったからです。しかし、それはかなり前のことであり、開発者はJavaScriptを情熱的に嫌っていました。振り返ってみると、JavaScriptの人気は2000年代後半に始まりました。ちょうどその頃、JavaScriptエンジンはさまざまな負荷ではるかに高速に動作し始め、おそらくこの言語に対する多くの人々の態度に影響を与えました。

当時、すべてのJSマイクロベンチマークの 先駆けであるApple SunSpiderからMozilla KrakenとGoogle V8まで、いわゆる伝統的なJavaScriptベンチマークが速度の測定に使用されていました。その後、GoogleベンチマークはOctaneに取って代わり、AppleはJetStreamをリリースしました。これらの従来のベンチマークは、JavaScriptのパフォーマンスを世紀の変わり目に誰も予想しなかったような高さにするために、信じられないほどの努力をしてきました。数千の加速が記録され、突然<script>使用が悪魔とのダンスでなくなり、クライアント側での計算の実行が可能になっただけでなく、奨励されました。

出典： V8およびWeb Assemblyを使用した高度なJSパフォーマンス、Chrome Developer Summit 2016、 @ s3ththompson

2016年には、すべての（重要な）JSエンジンが信じられないほどのパフォーマンスを達成し、Webアプリケーションはネイティブのものと同じくらい高速になりました（または高速になります）。エンジンには、高度に最適化されたマシンコードの短いシーケンスを生成する洗練された最適化コンパイラが付属しています。これは、さまざまなタイプ/フォームで利用可能な統計に応じて、各操作（プロパティ、バイナリ操作、比較、呼び出しなどへのアクセス）のタイプ/フォーム（タイプ/形状）を慎重に選択することで実現されます。これらの最適化の大部分は、SunSpiderやKrakenなどのマイクロベンチマーク、およびOctaneやJetStreamなどの統計パッケージによって決定されました。 asm.jsやEmscriptenなどのJavaScriptベースのテクノロジーのおかげで、今日ではJavaScriptで大規模なC ++アプリケーションをコンパイルし、ダウンロードやインストールなしでブラウザーで実行できます。たとえば、 AngryBotsでは簡単にオンラインで簡単にプレイできますが、以前はAdobe FlashやChrome PNaClなどの特別なプラグインが必要でした。

これらすべての成果の大部分は、マイクロベンチマークとパフォーマンス測定パッケージの存在、および従来のJSベンチマーク間で生じた競争のおかげで可能になりました。 SunSpiderについては何でも言うことができますが、それなしではJavaScriptのパフォーマンスが今日とほとんど変わらないことは明らかです。

しかし、十分な賞賛、それはコインの裏を見てみる時間です。すべての測定テストは、マイクロベンチマークであれ大きなパッケージであれ、時間が経つにつれて無関係になる運命にあります！なんで？ベンチマークは、あなたがそれで遊んで始めるまで、あなたに何かを教えることができるからです。特定のしきい値を超える（または超えない）とすぐに、特定のベンチマークで得られる最適化の一般的な適用性は指数関数的に低下します。

たとえば、Octaneをプロキシとして使用して、実際のWebアプリケーションのパフォーマンスを測定しました。そしてしばらくの間、彼はこの仕事に非常にうまく対処しました。しかし、今日では、Octaneと実際のアプリケーションでの時間の分布は大きく異なるため、Octaneをさらに最適化しても、実際のアプリケーション（Node.jsを含む）が大幅に改善されることはほとんどありません。

出典： Real-World JavaScript Performance 、BlinkOn 6 Conference、 @ tverwaes

JetStreamとOctaneの最新バージョンを含むJavaScriptパフォーマンスを測定するための従来のベンチマークのすべてが時代遅れになっているようになったことがますます明らかになったため、プロファイリングとV8およびChrome用の新しいインターセプターを追加して、実際のアプリケーションを測定する新しい方法を探し始めましたトレース。また、スクリプトの実行、ガベージコレクション、コンパイルなど、サイトの閲覧により多くの時間を費やすことを理解するためにツールを使用しました。研究結果は非常に興味深く、予想外でした。前の図からわかるように、Octaneを起動すると、70％以上の時間がJavaScriptとガベージコレクションに費やされますが、JavaScriptを使用したサイトの閲覧にかかる時間は常に30％未満であり、ガベージコレクションにかかる時間は5％以下です。しかし、解析とコンパイルには多くの時間がかかり、Octaneについては言えません。そのため、JavaScriptの実行を最適化するための相当な努力により、Octaneのオウムが大幅に増加しますが、サイトの読み込みはそれほど速くありません。さらに、JavaScriptの実行を最適化する趣味は、コンパイルに時間がかかるため、実際のアプリケーションのパフォーマンスを損なう可能性があります。または、コンパイル、IC、ランタイムを拡張する追加のパラメーターを追跡する必要があります。

JavaScript や DOMを含む、ブラウザ全体のパフォーマンスを測定しようとする別のベンチマークパッケージがあります： Speedometer 。彼は、さまざまな人気のあるWebフレームワークに実装されたシンプルなTodoMVCアプリケーションを起動することで、より現実的に測定にアプローチしようとします（今日は少し時代遅れですが、新しいバージョンがすでに作成されています）。パッケージには、新しいテスト（角度、エンバー、反応、バニラ、フライト、バックボーン）が含まれています。今日まで、スピードメーターは実際のアプリケーションのパフォーマンスを測定するための最も好ましいプロキシの役割のようです。ただし、これは2016年半ばのデータであり、Webで使用されるパターンが開発されると、すべてが既に変更される可能性があることに注意してください（たとえば、ICシステムをリファクタリングしてコストを大幅に削減し、パーサーを再設計します）。上記の状況はサイトの閲覧にのみ関係しているようですが、実際のNode.jsアプリケーションの場合、従来のピークパフォーマンスのベンチマークはプロキシロールに対してあまりうまく機能しないという非常に説得力のある証拠を受け取りました。

出典： Real-World JavaScript Performance 、BlinkOn 6 Conference、 @ tverwaes

おそらくこれはすべて幅広い読者にすでに知られているので、JSコミュニティが有用である理由を説明するいくつかの具体的な例だけを取り上げますが、ある時点でピークパフォーマンスの静的ベンチマークに注意を払わないことが非常に重要です。 JSエンジンがどのようにベンチマークに合格し、実際にどのようにそれを行うかの例から始めましょう。

悪名高いSunSpiderの例

従来のJSベンチマークに関する記事は、SunSpiderの明らかな問題について言及していなければ不完全です。実際の状況での適用性が制限されているパフォーマンステスト、 bitops-bitwise-and.jsから始めましょう。

特にC / C ++からJavaScriptへのトランスパイルコードでは、高速なビット単位のAND演算を必要とするアルゴリズムがいくつかあります。ただし、Webページが、エンジンが他のエンジンの2倍の速度でビット単位のAND演算を実行できるかどうかを考慮することはほとんどありません。おそらく、サイクルの最初の反復の後、bitwiseAndValueが0に等しくなり、次の599,999の反復の間はその値のままになることに気づいたでしょう。したがって、良好なパフォーマンスで、つまりまともなハードウェアで5ミリ秒を超えて実行するとすぐに、このサイクルの最初の反復のみが必要であり、残りはすべて時間の無駄（つまり、デッドコード後）であることを理解しようとして、このベンチマークの追跡を開始できます切断サイクル）。このJavaScriptへの変換を実行するには、以下を確認する必要があります。

bitwiseAndValueスクリプト実行前のグローバルオブジェクトの共通プロパティであるかどうか、
そのため、グローバルオブジェクトやそのプロトタイプなどのインターセプターはありません。

しかし、本当にベンチマークに勝ちたいと思っており、このための準備ができている場合は、1 ms未満でテストを実行できます。しかし、最適化の適用可能性はこの特定のケースによってのみ制限され、テストへの小さな変更はおそらく動作につながりません。

つまり、 bitops-bitwise-and.jsテストは、マイクロベンチマークの最悪の例でした。より実用的な例に移りましょう-string-tagcloud.js test 。実際、json.js json.js非常に初期のバージョンをjson.jsます。おそらく、このテストは以前のテストよりもはるかに合理的に見えるでしょう。しかし、ベンチマークプロファイルを詳しく見ると、彼が単一のeval式に多くの時間を費やしていることが明らかになります（解析およびコンパイルの合計実行時間の最大20％、コンパイルされたコードの実際の実行でも10％まで）。

よく見てみましょう： evalは一度だけ実行され、 tagとpopularityフィールドを持つ2501オブジェクトの配列を含むJSON文字列に渡されます：

  ([ { "tag": "titillation", "popularity": 4294967296 }, { "tag": "foamless", "popularity": 1257718401 }, { "tag": "snarler", "popularity": 613166183 }, { "tag": "multangularness", "popularity": 368304452 }, { "tag": "Fesapo unventurous", "popularity": 248026512 }, { "tag": "esthesioblast", "popularity": 179556755 }, { "tag": "echeneidoid", "popularity": 136641578 }, { "tag": "embryoctony", "popularity": 107852576 }, ... ])

明らかに、これらのオブジェクトリテラルを解析し、ネイティブコードを生成して実行するのは高価です。入力文字列をJSONとして解析し、対応するオブジェクトグラフを生成する方がはるかに安価です。ベンチマークの結果を改善するには、最初にevalをJSONとして解釈し、JSONとして読み取れない場合にのみ実際に解析、コンパイル、および実行を試みることができます（ただし、括弧をスキップするには追加の魔法が必要です）。 2007年には、 JSON.parseがまだ存在していなかったため、これは悪いハックではなかったでしょう。そして、2017年までに、これはJavaScriptエンジンの技術的義務に変わり、 evalの使用を遅くする可能性がありました。基本的に最新のJavaScriptにベンチマークを更新する

 --- string-tagcloud.js.ORIG 2016-12-14 09:00:52.869887104 +0100 +++ string-tagcloud.js 2016-12-14 09:01:01.033944051 +0100 @@ -198,7 +198,7 @@ replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(:?[eE][+\-]?\d+)?/g, ']'). replace(/(?:^|:|,)(?:\s*\[)+/g, ''))) { - j = eval('(' + this + ')'); + j = JSON.parse(this); return typeof filter === 'function' ? walk('', j) : j; }

生産性の即時向上につながります。現在、V8 LKGRのランタイムは36ミリ秒から26ミリ秒に短縮され、30％の改善があります。

 $ node string-tagcloud.js.ORIG Time (string-tagcloud): 36 ms. $ node string-tagcloud.js Time (string-tagcloud): 26 ms. $ node -v v8.0.0-pre $

これは、静的ベンチマークとパフォーマンステストパッケージの一般的な問題です。今日、誰も真剣にevalを使用してJSONデータを解析しません（パフォーマンスだけでなくセキュリティのため）。代わりに、過去5年間に記述されたすべてのコードはJSON.parseを使用します。さらに、実稼働環境でJSONを解析するためにevalを使用することはバグと見なすことができます！したがって、この古代のベンチマークでは、比較的最近作成されたコードの生産性を高めるためのエンジンの作成者の努力は考慮されていません。代わりに、 string-tagcloud.jsで良い結果を得るために、 eval不必要に複雑にすることが有用でしょう。

別の例-3d-cube.jsに進みましょう。このベンチマークは、多くの行列演算を実行します。これにより、最もインテリジェントなコンパイラーでさえ、単に実行することしかできません。ベンチマークは、ループ関数とそれが呼び出す関数の実行に多くの時間を費やします。

興味深い観察：関数RotateX 、 RotateY RotateZ常に定数パラメーターPhi呼び出されます。

これは、 Math.sinとMath.cosに対して常に204回同じ値を計算することを意味します。入力値は3つのみです。

0.017453292519943295
0.05235987755982989
0,08726646259971647

同じ正弦値と余弦値の不必要な計算を避けるために、以前に計算された値をキャッシュできます。以前は、V8はまさにそれを行いましたが、他のすべてのエンジンはまだそうしています。 V8から超越キャッシュと呼ばれるものを削除しました。これは、連続した同じ値を常に計算するとは限らないときに、実際の負荷の下で冗長性が顕著だったためです。 SunSpiderベンチマークの結果で多く失敗し、この特定の最適化を削除しましたが、ベンチマーク用に最適化すると同時に、実際のプロジェクトの結果を悪化させることは意味がないと確信しています。

ソース： arewefastyet.com

明らかに、そのような定数を使用する最良の方法-入力正弦/余弦-は、通常のインラインヒューリスティックヒューリスティックです。これは、置換のバランスを取り、定数フォールディングが有用な場合に呼び出しポイントでの置換設定などのさまざまな要因を考慮しようとします（定数フォールディング）（ RotateX 、 RotateY 、 RotateZの場合とRotateZ ）。しかし、いくつかの理由から、これはクランクシャフトコンパイラには適していませんでした。ただし、これはIgnitionおよびTurboFanの場合の合理的なオプションであり、代替ヒューリスティックの改善に既に取り組んでいます。

ガベージコレクションは有害と見なされます

特定のケースに加えて、SunSpiderには別の基本的な問題があります。それは、合計実行時間です。現在、適切なIntelハードウェアでは、V8エンジンは約200ミリ秒でベンチマーク全体を実行します（新しいスペースの生きているオブジェクトと古いスペースの断片化に依存します）が、ガベージコレクションの主要な一時停止は簡単に30ミリ秒に達します。また、インクリメンタルマーキングのコストは考慮されていません。これは、SunSpiderパッケージの合計実行時間の10％以上です。したがって、ガベージコレクションのためにエンジンの速度が10〜20％低下したくない場合は、SunSpiderの実行中にエンジンが開始されないようにする必要があります。

このために、さまざまなトリックが使用されますが、それらすべては、私が知る限り、実際のタスクにプラスの効果はありません。 V8はそれを行います：各SunSpiderテストは、新しいネイティブコンテキストに対応する新しい<iframe>で実行されるため、 <iframe>の作成と配置を登録するだけです（各SunSpiderテストに費やす時間は50ミリ秒未満です）。そして、テスト中ではなく、配置手順と作成手順の間でガベージコレクションが実行されます。このトリックはうまく機能し、99.99％のケースでは実際のプロジェクトには影響しません。しかし、V8がアプリケーションがSunSpiderテストのように見えると判断した場合、ガベージコレクターが強制的に実行され、これが作業速度に悪影響を及ぼします。したがって、アプリケーションをSunSpiderのように見せないでください 。

SunSpiderに関連する他の例を挙げることはできますが、役に立つとは思いません。優れたパフォーマンスの結果を上回るためにSunSpiderを最適化することは、実際のアプリケーションには意味がないことは、すでに明らかであることを願っています。エンジンはこのパッケージにのみ有用で、実際の状況では有害になる可能性のある奇妙なハックを使用できるため、SunSpiderがもうなかったら世界は恩恵を受けると思います。

残念ながら、記者がブラウザのパフォーマンスをどのように考えているかを比較するとき、SunSpiderは依然としてマスコミで非常に頻繁に使用されています。または、さらに悪いことに、スマートフォンを比較します！もちろん、メーカーの関心もここに示されています。 Androidキャンプは、ChromeがSunSpider（およびその他の無意味なベンチマーク）で良好な結果を示すことが重要です。スマートフォンメーカーは製品を販売することで稼ぐ必要があり、これには良いレビューが必要です。一部の企業は、V8の古いバージョンをスマートフォンに搭載して出荷しているため、SunSpiderでより良い結果を示しています。その結果、ユーザーは閉じられていないセキュリティホールに陥りますが、これは後のバージョンで修正されています。さらに、実際にはV8の古いバージョンはより遅く動作します！

出典：Galaxy S7およびS7 Edgeのレビュー：サムスンの最高の技術をさらに磨き上げるwww.engadget.com

JavaScriptコミュニティが客観的なパフォーマンスデータを取得することに本当に関心がある場合、ジャーナリストがブラウザーとスマートフォンを比較するときに従来のベンチマークの使用を停止する必要があります。各ブラウザでベンチマークを実行し、取得した数値を比較する方が簡単であることを理解していますが、その場合は、どうかお問い合わせください。 -少なくとも何らかの形で現在の状況に対応するベンチマークに注意してください。それが本当のウェブページです。ブラウザのベンチマークで2台のスマートフォンを比較する必要がある場合は、少なくともSpeedometerを使用してください。

クラーケンとのそれほど明白でない状況

Krakenベンチマークは、2010年9月にMozillaによってリリースされました。コードの断片と実際のアプリケーションのコアが含まれていると主張されました。クラーケンは、SunSpiderやOctaneほどJavaScriptのパフォーマンスに影響を与えていないため、あまり時間をかけません。 audio-oscillator.jsテストの例のみを説明します。

テストは500回、 calcOsc関数を呼び出します。最初に、 sine Oscillatorグローバルに対してgenerateを呼び出し、次に新しいOscillator作成し、それに対してgenerateを呼び出して、それをsine Oscillator追加します。ここでこれが行われる理由について詳しくは説明しませんが、 Oscillatorプロトタイプのgenerateメソッドを見てみましょう。

コードを見ると、大部分の時間は配列へのアクセス、乗算、またはMath.roundの循環呼び出しで占められていると想定できます。 runtime Oscillator.prototype.generate offset % this.waveTableLength . Intel-, , 20 % idiv , (modulus). : waveTableLength Oscillator 2048, Oscillator .

, — , Intel idiv . calcOsc /. sine Oscillator , calcOsc .

, . V8 - , + , * % , , , (. Fast arithmetic for dynamic languages ).

fullcodegen Crankshaft, BinaryOpIC MOD . V8 (c Crankshaft fullcodegen)

 $ ~/Projects/v8/out/Release/d8 --trace-ic audio-oscillator.js [...SNIP...] [BinaryOpIC(MOD:None*None->None) => (MOD:Smi*2048->Smi) @ ~Oscillator.generate+598 at audio-oscillator.js:697] [...SNIP...] $

, BinaryOpIC (constant feedback) , , ( Smi V8), . --print-opt-code --code-comments , , Crankshaft Oscillator.prototype.generate :

  [...SNIP...] ;;; <@80,#84> load-named-field 0x133a0bdacc4a 330 8b4343 movl rax,[rbx+0x43] ;;; <@83,#86> compare-numeric-and-branch 0x133a0bdacc4d 333 3d00080000 cmp rax,0x800 0x133a0bdacc52 338 0f85ff000000 jnz 599 (0x133a0bdacd57) [...SNIP...] ;;; <@90,#94> mod-by-power-of-2-i 0x133a0bdacc5b 347 4585db testl r11,r11 0x133a0bdacc5e 350 790f jns 367 (0x133a0bdacc6f) 0x133a0bdacc60 352 41f7db negl r11 0x133a0bdacc63 355 4181e3ff070000 andl r11,0x7ff 0x133a0bdacc6a 362 41f7db negl r11 0x133a0bdacc6d 365 eb07 jmp 374 (0x133a0bdacc76) 0x133a0bdacc6f 367 4181e3ff070000 andl r11,0x7ff [...SNIP...] ;;; <@127,#88> deoptimize 0x133a0bdacd57 599 e81273cdff call 0x133a0ba8406e [...SNIP...]

, this.waveTableLength ( rbx this ), , 2048 ( 0x800). , idiv ( r11 i ), .

, , , , : ! , ( , ). idiv , BinaryOpIC Smi*Smi->Smi . , Oscillator , waveTableLength generate . 20 % , Oscillator '; (non-local penalization).

 --- audio-oscillator.js.ORIG 2016-12-15 22:01:43.897033156 +0100 +++ audio-oscillator.js 2016-12-15 22:02:26.397326067 +0100 @@ -1931,6 +1931,10 @@ var frequency = 344.53; var sine = new Oscillator(Oscillator.Sine, frequency, 1, bufferSize, sampleRate); +var unused = new Oscillator(Oscillator.Sine, frequency, 1, bufferSize, sampleRate); +unused.waveTableLength = 1024; +unused.generate(); + var calcOsc = function() { sine.generate();

audio-oscillator.js , Oscillator waveTableLength , :

 $ ~/Projects/v8/out/Release/d8 audio-oscillator.js.ORIG Time (audio-oscillator-once): 64 ms. $ ~/Projects/v8/out/Release/d8 audio-oscillator.js Time (audio-oscillator-once): 81 ms. $

. , , , . , , . , - - BinaryOpIC , 20- ( , ). , , .

JavaScript. , , JavaScript . , , () . , idiv , , ( ). TurboFan, Crankshaft, runtime , , () ():

 if 0 < rhs then msk = rhs - 1 if rhs & msk != 0 then lhs % rhs else if lhs < 0 then -(-lhs & msk) else lhs & msk else if rhs < -1 then lhs % rhs else zero

( TurboFan):

 $ ~/Projects/v8/out/Release/d8 --turbo audio-oscillator.js.ORIG Time (audio-oscillator-once): 69 ms. $ ~/Projects/v8/out/Release/d8 --turbo audio-oscillator.js Time (audio-oscillator-once): 69 ms. $

, , , , , . , JS- , Kraken , TurboFan. TurboFan Crankshaft, , , , ! , , , , . . . , , , .

Kraken , JS- — Octane.

Octane

Octane — V8. Google 2012 , Octane 2.0 — 2013- . 15 , — Splay Mandreel — (throughput) . , Microsofts TypeScript, asm.js zlib, (ray tracer), . . JavaScript, 2012 .

, Octane JavaScript 2012—2013-. . Octane (, TypeScript zlib Emscripten , Mandreel ).

, Ember AngularJS , JavaScript, Octane () . JavaScript , JS- , , Octane. , , Octane .

Octane, . , ! , Octane — JavaScript, . , JS- , , Octane — ! , , !

Box2D, Box2DWeb , , JavaScript. , JS- . , , , ( ). D.prototype.UpdatePairs ():

 D.prototype.UpdatePairs = function(b) { var e = this; var f = e.m_pairCount = 0, m; for (f = 0; f < e.m_moveBuffer.length; ++f) { m = e.m_moveBuffer[f]; var r = e.m_tree.GetFatAABB(m); e.m_tree.Query(function(t) { if (t == m) return true; if (e.m_pairCount == e.m_pairBuffer.length) e.m_pairBuffer[e.m_pairCount] = new O; var x = e.m_pairBuffer[e.m_pairCount]; x.proxyA = t < m ? t : m; x.proxyB = t >= m ? t : m; ++e.m_pairCount; return true }, r) } for (f = e.m_moveBuffer.length = 0; f < e.m_pairCount;) { r = e.m_pairBuffer[f]; var s = e.m_tree.GetUserData(r.proxyA), v = e.m_tree.GetUserData(r.proxyB); b(s, v); for (++f; f < e.m_pairCount;) { s = e.m_pairBuffer[f]; if (s.proxyA != r.proxyA || s.proxyB != r.proxyB) break; ++f } } };

, , e.m_tree.Query :

 function(t) { if (t == m) return true; if (e.m_pairCount == e.m_pairBuffer.length) e.m_pairBuffer[e.m_pairCount] = new O; var x = e.m_pairBuffer[e.m_pairCount]; x.proxyA = t < m ? t : m; x.proxyB = t >= m ? t : m; ++e.m_pairCount; return true }

, , . 4—7 % runtime- Compare , (abstract relational comparison).

runtime- CompareICStub , :

 x.proxyA = t < m ? t : m; x.proxyB = t >= m ? t : m;

99 % ! どうして？ , JavaScript, . t m — L , . Symbol.toPrimitive , "toString" , "valueOf" Symbol.toStringTag , . t < m , :

ToPrimitive ( t , hint Number ).
OrdinaryToPrimitive ( t , "number" ), Symbol.toPrimitive .
t.valueOf() , t , Object.prototype.valueOf .
t.toString() , "[object Object]" , Object.prototype.toString , Symbol.toStringTag L .
ToPrimitive ( m , hint Number ).
OrdinaryToPrimitive ( m , "number" ), Symbol.toPrimitive.
m.valueOf() , m, Object.prototype.valueOf .
m.toString() , "[object Object]" , Object.prototype.toString , Symbol.toStringTag L .
"[object Object]" < "[object Object]" ,

。

t >= m , true . , . : , :

 --- octane-box2d.js.ORIG 2016-12-16 07:28:58.442977631 +0100 +++ octane-box2d.js 2016-12-16 07:29:05.615028272 +0100 @@ -2021,8 +2021,8 @@ if (t == m) return true; if (e.m_pairCount == e.m_pairBuffer.length) e.m_pairBuffer[e.m_pairCount] = new O; var x = e.m_pairBuffer[e.m_pairCount]; - x.proxyA = t < m ? t : m; - x.proxyB = t >= m ? t : m; + x.proxyA = m; + x.proxyB = t; ++e.m_pairCount; return true },

13 %, :

 $ ~/Projects/v8/out/Release/d8 octane-box2d.js.ORIG Score (Box2D): 48063 $ ~/Projects/v8/out/Release/d8 octane-box2d.js Score (Box2D): 55359 $

? , , CompareIC : (map) (known receiver map tracking) ( V8 map — + ). . :

 $ ~/Projects/v8/out/Release/d8 --trace-ic octane-box2d.js [...SNIP...] [CompareIC in ~+557 at octane-box2d.js:2024 ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(RECEIVER+RECEIVER=KNOWN_RECEIVER))#LT @ 0x1d5a860493a1] [CompareIC in ~+649 at octane-box2d.js:2025 ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(RECEIVER+RECEIVER=KNOWN_RECEIVER))#GTE @ 0x1d5a860496e1] [...SNIP...] $

CompareIC , « » « » RECEIVER ' (JavaScript- V8). (map) 0x1d5a860493a1 , L . false true , : — 0x1d5a860493a1 . L , the Symbol.toPrimitive , "valueOf" "toString" . Symbol.toStringTag . Crankshaft Symbol.toStringTag :

: , . , , , JS- . , ! , ( , true false , ). , , . ES2015, , (ES2015 — !).

Mandreel. C/C++ JavaScript. asm.js , Emscripten , ( ). Octane Bullet , Mandreel . MandreelLatency, . , Mandreel , . , . , . , .

Mandreel global_init , . , ( ), , , ( ). V8 . , , , . global_init Mandreel , + + . global_init , .

: arewefastyet.com .

global_init , 200- . , , , , ( ).

, — splay.js . , (splay trees) ( ). : . (buckets) , . ! 理論的には。 , :

, , , , SplayLatency. なんで？ , , . , (generational garbage collector), V8: ( generational hypothesis ), . V8 :

 $ out/Release/d8 --trace-gc --noallocation_site_pretenuring octane-splay.js [20872:0x7f26f24c70d0] 10 ms: Scavenge 2.7 (6.0) -> 2.7 (7.0) MB, 1.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 12 ms: Scavenge 2.7 (7.0) -> 2.7 (8.0) MB, 1.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 14 ms: Scavenge 3.7 (8.0) -> 3.6 (10.0) MB, 0.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 18 ms: Scavenge 4.8 (10.5) -> 4.7 (11.0) MB, 2.5 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 22 ms: Scavenge 5.7 (11.0) -> 5.6 (16.0) MB, 2.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 28 ms: Scavenge 8.7 (16.0) -> 8.6 (17.0) MB, 4.3 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 35 ms: Scavenge 9.6 (17.0) -> 9.6 (28.0) MB, 6.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 49 ms: Scavenge 16.6 (28.5) -> 16.4 (29.0) MB, 8.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 65 ms: Scavenge 17.5 (29.0) -> 17.5 (52.0) MB, 15.3 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 93 ms: Scavenge 32.3 (52.5) -> 32.0 (53.5) MB, 17.6 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 126 ms: Scavenge 33.4 (53.5) -> 33.3 (68.0) MB, 31.5 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 151 ms: Scavenge 47.9 (68.0) -> 47.6 (69.5) MB, 15.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 183 ms: Scavenge 49.2 (69.5) -> 49.2 (84.0) MB, 30.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 210 ms: Scavenge 63.5 (84.0) -> 62.4 (85.0) MB, 14.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 241 ms: Scavenge 64.7 (85.0) -> 64.6 (99.0) MB, 28.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 268 ms: Scavenge 78.2 (99.0) -> 77.6 (101.0) MB, 16.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 298 ms: Scavenge 80.4 (101.0) -> 80.3 (114.5) MB, 28.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 324 ms: Scavenge 93.5 (114.5) -> 92.9 (117.0) MB, 16.4 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 354 ms: Scavenge 96.2 (117.0) -> 96.0 (130.0) MB, 27.6 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 383 ms: Scavenge 108.8 (130.0) -> 108.2 (133.0) MB, 16.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 413 ms: Scavenge 111.9 (133.0) -> 111.7 (145.5) MB, 27.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 440 ms: Scavenge 124.1 (145.5) -> 123.5 (149.0) MB, 17.4 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 473 ms: Scavenge 127.6 (149.0) -> 127.4 (161.0) MB, 29.5 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 502 ms: Scavenge 139.4 (161.0) -> 138.8 (165.0) MB, 18.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 534 ms: Scavenge 143.3 (165.0) -> 143.1 (176.5) MB, 28.5 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 561 ms: Scavenge 154.7 (176.5) -> 154.2 (181.0) MB, 19.0 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 594 ms: Scavenge 158.9 (181.0) -> 158.7 (192.0) MB, 29.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 622 ms: Scavenge 170.0 (192.5) -> 169.5 (197.0) MB, 19.5 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 655 ms: Scavenge 174.6 (197.0) -> 174.3 (208.0) MB, 28.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 683 ms: Scavenge 185.4 (208.0) -> 184.9 (212.5) MB, 19.4 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 715 ms: Scavenge 190.2 (213.0) -> 190.0 (223.5) MB, 27.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 743 ms: Scavenge 200.7 (223.5) -> 200.3 (228.5) MB, 19.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 774 ms: Scavenge 205.8 (228.5) -> 205.6 (239.0) MB, 27.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 802 ms: Scavenge 216.1 (239.0) -> 215.7 (244.5) MB, 19.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 833 ms: Scavenge 221.4 (244.5) -> 221.2 (254.5) MB, 26.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 861 ms: Scavenge 231.5 (255.0) -> 231.1 (260.5) MB, 19.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 892 ms: Scavenge 237.0 (260.5) -> 236.7 (270.5) MB, 26.3 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 920 ms: Scavenge 246.9 (270.5) -> 246.5 (276.0) MB, 20.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 951 ms: Scavenge 252.6 (276.0) -> 252.3 (286.0) MB, 25.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 979 ms: Scavenge 262.3 (286.0) -> 261.9 (292.0) MB, 20.3 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1014 ms: Scavenge 268.2 (292.0) -> 267.9 (301.5) MB, 29.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1046 ms: Scavenge 277.7 (302.0) -> 277.3 (308.0) MB, 22.4 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1077 ms: Scavenge 283.8 (308.0) -> 283.5 (317.5) MB, 25.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1105 ms: Scavenge 293.1 (317.5) -> 292.7 (323.5) MB, 20.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1135 ms: Scavenge 299.3 (323.5) -> 299.0 (333.0) MB, 24.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1164 ms: Scavenge 308.6 (333.0) -> 308.1 (339.5) MB, 20.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1194 ms: Scavenge 314.9 (339.5) -> 314.6 (349.0) MB, 25.0 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1222 ms: Scavenge 324.0 (349.0) -> 323.6 (355.5) MB, 21.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1253 ms: Scavenge 330.4 (355.5) -> 330.1 (364.5) MB, 25.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1282 ms: Scavenge 339.4 (364.5) -> 339.0 (371.0) MB, 22.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1315 ms: Scavenge 346.0 (371.0) -> 345.6 (380.0) MB, 25.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1413 ms: Mark-sweep 349.9 (380.0) -> 54.2 (305.0) MB, 5.8 / 0.0 ms (+ 87.5 ms in 73 steps since start of marking, biggest step 8.2 ms, walltime since start of marking 131 ms) finalize incremental marking via stack guard GC in old space requested [20872:0x7f26f24c70d0] 1457 ms: Scavenge 65.8 (305.0) -> 65.1 (305.0) MB, 31.0 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1489 ms: Scavenge 69.9 (305.0) -> 69.7 (305.0) MB, 27.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1523 ms: Scavenge 80.9 (305.0) -> 80.4 (305.0) MB, 22.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1553 ms: Scavenge 85.5 (305.0) -> 85.3 (305.0) MB, 24.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1581 ms: Scavenge 96.3 (305.0) -> 95.7 (305.0) MB, 18.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1616 ms: Scavenge 101.1 (305.0) -> 100.9 (305.0) MB, 29.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1648 ms: Scavenge 111.6 (305.0) -> 111.1 (305.0) MB, 22.5 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1678 ms: Scavenge 116.7 (305.0) -> 116.5 (305.0) MB, 25.0 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1709 ms: Scavenge 127.0 (305.0) -> 126.5 (305.0) MB, 20.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1738 ms: Scavenge 132.3 (305.0) -> 132.1 (305.0) MB, 23.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1767 ms: Scavenge 142.4 (305.0) -> 141.9 (305.0) MB, 19.6 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1796 ms: Scavenge 147.9 (305.0) -> 147.7 (305.0) MB, 23.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1825 ms: Scavenge 157.8 (305.0) -> 157.3 (305.0) MB, 19.9 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1853 ms: Scavenge 163.5 (305.0) -> 163.2 (305.0) MB, 22.2 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1881 ms: Scavenge 173.2 (305.0) -> 172.7 (305.0) MB, 19.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1910 ms: Scavenge 179.1 (305.0) -> 178.8 (305.0) MB, 23.0 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1944 ms: Scavenge 188.6 (305.0) -> 188.1 (305.0) MB, 25.1 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 1979 ms: Scavenge 194.7 (305.0) -> 194.4 (305.0) MB, 28.4 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 2011 ms: Scavenge 204.0 (305.0) -> 203.6 (305.0) MB, 23.4 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 2041 ms: Scavenge 210.2 (305.0) -> 209.9 (305.0) MB, 23.8 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 2074 ms: Scavenge 219.4 (305.0) -> 219.0 (305.0) MB, 24.5 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 2105 ms: Scavenge 225.8 (305.0) -> 225.4 (305.0) MB, 24.7 / 0.0 ms allocation failure [20872:0x7f26f24c70d0] 2138 ms: Scavenge 234.8 (305.0) -> 234.4 (305.0) MB, 23.1 / 0.0 ms allocation failure [...SNIP...] $

: ( ). , allocation site pretenuring . (allocation sites), , . , — pretenure .

 $ out/Release/d8 --trace-gc octane-splay.js [20885:0x7ff4d7c220a0] 8 ms: Scavenge 2.7 (6.0) -> 2.6 (7.0) MB, 1.2 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 10 ms: Scavenge 2.7 (7.0) -> 2.7 (8.0) MB, 1.6 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 11 ms: Scavenge 3.6 (8.0) -> 3.6 (10.0) MB, 0.9 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 17 ms: Scavenge 4.8 (10.5) -> 4.7 (11.0) MB, 2.9 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 20 ms: Scavenge 5.6 (11.0) -> 5.6 (16.0) MB, 2.8 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 26 ms: Scavenge 8.7 (16.0) -> 8.6 (17.0) MB, 4.5 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 34 ms: Scavenge 9.6 (17.0) -> 9.5 (28.0) MB, 6.8 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 48 ms: Scavenge 16.6 (28.5) -> 16.4 (29.0) MB, 8.6 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 64 ms: Scavenge 17.5 (29.0) -> 17.5 (52.0) MB, 15.2 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 96 ms: Scavenge 32.3 (52.5) -> 32.0 (53.5) MB, 19.6 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 153 ms: Scavenge 61.3 (81.5) -> 57.4 (93.5) MB, 27.9 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 432 ms: Scavenge 339.3 (364.5) -> 326.6 (364.5) MB, 12.7 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 666 ms: Scavenge 563.7 (592.5) -> 553.3 (595.5) MB, 20.5 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 825 ms: Mark-sweep 603.9 (644.0) -> 96.0 (528.0) MB, 4.0 / 0.0 ms (+ 92.5 ms in 51 steps since start of marking, biggest step 4.6 ms, walltime since start of marking 160 ms) finalize incremental marking via stack guard GC in old space requested [20885:0x7ff4d7c220a0] 1068 ms: Scavenge 374.8 (528.0) -> 362.6 (528.0) MB, 19.1 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 1304 ms: Mark-sweep 460.1 (528.0) -> 102.5 (444.5) MB, 10.3 / 0.0 ms (+ 117.1 ms in 59 steps since start of marking, biggest step 7.3 ms, walltime since start of marking 200 ms) finalize incremental marking via stack guard GC in old space requested [20885:0x7ff4d7c220a0] 1587 ms: Scavenge 374.2 (444.5) -> 361.6 (444.5) MB, 13.6 / 0.0 ms allocation failure [20885:0x7ff4d7c220a0] 1828 ms: Mark-sweep 485.2 (520.0) -> 101.5 (519.5) MB, 3.4 / 0.0 ms (+ 102.8 ms in 58 steps since start of marking, biggest step 4.5 ms, walltime since start of marking 183 ms) finalize incremental marking via stack guard GC in old space requested [20885:0x7ff4d7c220a0] 2028 ms: Scavenge 371.4 (519.5) -> 358.5 (519.5) MB, 12.1 / 0.0 ms allocation failure [...SNIP...] $

SplayLatency 250 %!

: arewefastyet.com .

SIGPLAN , , allocation site pretenuring . , . ( 1 , 2 , 3 ), allocation site pretenuring . , Ember.js (, - allocation site pretenuring).

allocation site pretenuring, , — , ( - , ). , , , (-) (-) (allocation site) tenured , . - , , , (incremental marking).

. , , Orinoco . (unified heap), , . : , , . , SplayLatency , . . (concurrent marking) , (throughput).

おわりに

, , , - . , , , ! , . , , .

: 2016-: Chrome vs. Firefox vs. Edge, venturebeat.com .

, — . , JavaScript . , , . , Node.js ( V8, ChakraCore)!

: JavaScript- . , . JavaScript , . Chrome , . , , Speedometer , - .

よろしくお願いします！

従来のJavaScriptベンチマークに関する真実

悪名高いSunSpiderの例

ガベージコレクションは有害と見なされます

クラーケンとのそれほど明白でない状況

Octane

おわりに

More articles: