5

Tracemonkey、Squirrelfish、および V8 プロジェクトを通じて、大文字の C、大文字の S コンピューター サイエンスが Javascript に組み込まれています。これらのプロジェクト (または他のプロジェクト) のいずれかが DOM 操作のパフォーマンスに対処していますか? それとも、純粋に Javascript 計算に関連していますか?

4

2 に答える 2

13

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

JSエンジンの改善がパフォーマンスにどのように影響するかは、パフォーマンスの改善に使用される特定の手法と、DOM->JSブリッジのパフォーマンスにある程度依存します。

前者の例は、JS関数へのすべての呼び出しに対するTraceMonkeyの依存です。トレースは、JSがインライン化できないコード（ネイティブコード、真の多態性再帰、例外ハンドラー）にヒットしたポイントで実行パスを効果的にインライン化するため、トレースは中止され、実行はインタープリターにフォールバックします。TM開発者は、トレースできるコードの量を改善するためにかなりの作業を行っていますが（多態的な再帰の処理を含む）、任意のネイティブ関数（DOMなど）への呼び出しを実際にトレースすることはできません。そのため、彼らはJSで（または少なくともJSに適した方法で）より多くのDOMを実装することを検討していると思います。とは言うものの、コードが追跡可能である場合、TMはほとんどの「オブジェクト」を下げることができるため、非常に優れた仕事をすることができます。

JavaScriptCore（SquirrelFish Extremeが存在する場所）とV8は、すべてのJSコードをすぐにJITし、より投機的なコードを生成するという点で、より類似したアプローチを採用しています（たとえば、実行している場合は、数値a*bを想定aしbてフォールバックするコードを生成します）そうでない場合は、コードが非常に遅くなります）。これには、トレースに比べて多くの利点があります。つまり、ネイティブコードを呼び出すか、例外をスローするかなどに関係なく、すべてのコードをjitできるため、1回のDOM呼び出しでパフォーマンスが低下することはありません。欠点は、すべてのコードが投機的であるということです。TMはMath.floorなどへの呼び出しをa=Math.floor(0.5)インライン化しますが、JSC/V8が実行できる最善の方法は->と同等です。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は、タイプをa1回だけチェックするコードを生成します。等しい）単に乗算a.xしa.y、それらが数値であることを確認せずに。

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

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

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

..

Errmmm、それは意図したよりも幾分長く続いたので、元の質問に対する短い答えは「それは依存する」です：D

于 2009-01-02T08:42:34.547 に答える
4

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

DOMの最適化は、リス、 サル、 クモ、魚のもう1つのやかんです。レイアウトやレンダリングエンジンも機能し、各ブラウザには独自の実装と最適化の戦略があります。

于 2009-01-02T06:22:56.233 に答える