さまざまなJavascript最適化プロジェクトはDOMのパフォーマンスにどのように影響しますか？

Question

Tracemonkey、Squirrelfish、およびV8プロジェクトを介してJavascriptに移行する資本C、資本Sのコンピューターサイエンスがたくさんあります。これらのプロジェクト（または他のプロジェクト）のいずれかがDOM操作のパフォーマンスに対処していますか、それとも純粋にJavascriptの計算に関連していますか？

Answer 1

純粋なDOM操作（getElementById / Tagname / Selector、nextChildなど）のパフォーマンスは、既に純粋なC ++にあるため、影響を受けません。

JSエンジンの改善がパフォーマンスにどのように影響するかは、パフォーマンスの改善に使用される特定の手法と、DOM-<！> gt; JSブリッジのパフォーマンスによって異なります。

前者の例は、JS関数へのすべての呼び出しに対するTraceMonkeyの依存関係です。トレースは、JSがインライン化できないコード（ネイティブコード、真のポリモーフィックな再帰、例外ハンドラー）にヒットするポイントで実行パスを効果的にインライン化するため、トレースは中止され、実行はインタープリターにフォールバックします。 TM開発者は、トレースできるコードの量を改善するために非常に多くの作業を行っています（ポリモーフィックな再帰の処理を含む）が、任意のネイティブ関数（DOMなど）の呼び出しを現実的にトレースすることは実行できません。そのため、私は彼らがJSで（または少なくともJSフレンドリーな方法で）より多くのDOMを実装しようとしていると信じています。とは言っても、コードが追跡可能である場合、TMはほとんどの<！> quot; objects <！> quot;を下げることができるため、非常に優れた仕事をすることができます。より効率的および/またはネイティブの同等物（例：JS Number実装の代わりにmachine intを使用）。

JavaScriptCore（SquirrelFish Extremeが存在する場所）とV8には、すべてのJSコードを即座にJITし、より投機的なコードを生成するという点でより類似したアプローチがあります（たとえば、a*b aおよびbは数値であり、そうでない場合は非常に遅いコードにフォールバックします。これには、トレースよりも多くの利点があります。つまり、ネイティブコードを呼び出すか例外をスローするかどうかに関係なく、すべてのコードをjitできるため、1回のDOM呼び出しでパフォーマンスが損なわれることはありません。欠点は、すべてのコードが投機的であるということです。TMはMath.floorなどへのインライン呼び出しを行いますが、JSC / V8でできることはa=Math.floor(0.5)-<！> gt;と同等です。 a=(Math.floor == realFloor) ? inline : Math.floor(0.5)これには、パフォーマンスとメモリ使用量の両方にコストがかかりますが、特に実行可能ではありません。この理由は、前もってコンパイルされているためです。TMは、実行後にコードをJITするだけです（したがって、どの関数が呼び出されたかを正確に知っています）。JSCとV8は、そのような仮定を行うための実際の基盤がなく、基本的に推測する必要がありますこの）。 V8とJSCがこの問題を補おうとすることの1つは、過去に見たものを追跡し、それを実行パスに組み込むことです。両方とも、特にホットなケースで、このキャッシングを行うためにテクニックの組み合わせを使用します命令ストリームの小さな部分を書き換え、その他の場合は帯域外キャッシュを保持します。大まかに言えば、あなたが行くコードを持っている場合

a.x * a.y

V8およびJSCは、「暗黙的なタイプ」/「構造」を2回チェックします（アクセスごとに1回）。次に、a.xとa.yが両方とも数字であることを確認します。一方、TMは、 <=>は1回だけであり、（すべてが等しい場合）数字であることを確認せずに<=>と<=>を掛けることができます。

現在、純粋な実行速度を見ている場合、特定のタスクで各エンジンが他のタスクよりも優れているように見えるため、混合バッグのようなものがあります-TraceMonkeyは多くの純粋な数学テストで勝ち、V8は非常に動的なケースで勝ちます、JSCミックスがあれば勝ちます。もちろん、今日はそれは本当ですが、パフォーマンスを改善するために全員が懸命に働いているので、明日ではないかもしれません。

私が言及した他の問題は、DOM <！> lt;-<！> gt; JSバインディングコストでした-これは実際にWebパフォーマンスで非常に重要な役割を果たすことができます。これの最も良い例はSafari 3.1 / 2 vsです。 DromaeoベンチマークでのChrome。 ChromeはWebKitのSafari 3.1 / 2ブランチをベースにしているため、同様のDOMパフォーマンスを想定するのは比較的安全です（コンパイラの違いによってある程度のばらつきが生じる可能性があります）。このベンチマークでは、Safari 3.1 / 2は実際にChromeに勝っていますが、明らかにはるかに遅いJSエンジン。これは基本的に、JSC / WebCore（WebKitのdom / rendering / etc）とV8 / WebCoreの間のより効率的なバインディングによるものです

現在、TMのDOMバインディングを見ると、やりたいすべての作業を完了していないため（不正確）、インタプリタにフォールバックするだけなので、不公平に見えます：-（

..

Errmmm、意図したよりもやや長かったので、元の質問への短い答えは<！> quot; it depend <！> quot; ：D

Answer 2

これらは純粋なJavaScriptです。特定のDOMメソッド呼び出しがJSで 実装されていない限り、それらはほとんど効果がありません（ただし、そのような呼び出しのオーバーヘッドを削減する作業が行われていないとは限りません） ）。

DOM最適化は、「 squirrels monkeys spiders fish」というまったく別のケトルです...各ブラウザには独自の実装および最適化戦略があります。