Google Speed Tracer を使用して YUI3 アプリケーションのプロファイルを作成しようとしています。
最初のスナップショットは次のとおりです。
これまでのところ、ST は 195ms かかる場所を示しています。だから、私はそれを拡大します：
さらに良いですね。ここで、ST は問題のある行に移動します。
しかし、次は何ですか？つまり、ここに行があります：
return ('scrollTop' in node) ? node.scrollTop : Y.DOM.docScrollY(node);
スタック トレースはここで終了するため、返されると仮定しnode.scrollTopます。これは単なる JS プロパティ アクセスです。
では、この時点でスタイルの再計算が行われ、実行時間が 36 ミリ秒になったという主張の背後にある論理は何でしょうか?
誰かが私にそれを説明できますか？
ここで発生する可能性が最も高いのは、スタイルの再計算を必要とする DOM やスタイルシートへの変更が蓄積されていることです。しかし、ほとんどのレンダリング エンジン (間違いなく WebKit) は、スタイルの再計算 (およびレイアウトとレンダリング) を可能な限り延期します。現在のイベント ハンドラが制御をネイティブ コードに戻すと、スタイルの再計算、レイアウト、およびレンダリングがすべて順番に実行されるのが最善のケースです。
しかし、早期に再計算やレイアウトを強制することができるものはたくさんあります。最も一般的なのは、scrollTop計算する必要がある DOM 要素のプロパティ (例: ) にアクセスすることです。などの他のプロパティoffset[Left Top Width Height]も、一般的にスタイルの再計算とレイアウトを強制します。レンダリング エンジンは (ほとんどの場合) Javascript VM でシングル スレッド化されているため、ブラウザーはこれを「バックグラウンドで」行うことができません。そのため、通常はネイティブ コードが呼び出されるまで待機する必要があります。
スクリーンショットからはわかりにくいですが、私が見る限り、このイベントの直前に非常に大きな HTML のチャンク (18 ミリ秒相当) が解析されているように見えます。これは、かなりの量のスタイルの再計算とレイアウトに相当する可能性があります。 (後者は直後に 26ms かかります)。TableView._defRenderBodyFr()また、このゲッターが呼び出される直前に、かなりの数のテーブル行を追加/変更したと思われるスタック トレースも表示されます。コードはTableViewおそらく大きな HTML 文字列を構築しますが、HTML の解析 (および DOM の構築) は で設定されたときにのみ支払いましたが、コードがプロパティ (この場合は )innerHTMLにアクセスしようとするとすぐに、scrollTopスタイルの再計算とレイアウト。
各ミューテーションの影響を受ける行の数を減らすことで、これらのコストをより小さなチャンクに分割できるはずです (したがって、UI スレッドに息を吹き込み、一般的に応答性を高める機会が与えられます)。私は YUI の専門家ではないので、YUI の TableView でどのように行うかはわかりません。