The Performance of Dynamic Site (id:amachang)

JavaScript イベント まとめ

日本Javaユーザーグループ

概要

  • JavaScriptの誤解
  • 重くしている犯人
  • プロファイラ

JavaScriptの誤解

  • JavaScriptは遅い
    • 速いです

重くしている犯人

  • DOM
    • DOMをフェーズに分けて考える
  1. JavaScriptとコンポーネント(C++)との通信(取得)
  2. DOMノードの追加、値の変更
  3. スタイルの計算
  4. レイアウトの計算

XPConnectやCOMとの通信
単純なプロパティアクセスの数十倍(IE以外は無視しておk)
COMは重い
通信回数＝DOMのオブジェクトの「.」の数

  • DOMノードの追加、値の変更

取得の場合と同じ「.」の数
ノードに変更したというフラグが立つ
parent.appendChild(child)だとparentとchildにフラグが立つ。
重要：再計算がJavaScriptの実行後に行われる事がある
→JavaScript内でのベンチやプロファイリングが役に立たない

  • スタイルの計算

一番最適化が効く所

    • 変更フラグが経っているノードがあるままJavaScriptが終了した
    • 変更フラグが経っている状態でスタイルの再計算が必要な操作が行われた
      • offsetWidthの取得とか

「変更→再計算が必要な操作(取得)→変更」というのが癌


再計算が行われる代表的操作

再計算が行われる範囲
classを設定した場合
自身・子孫・弟・弟の子孫
styleプロパティの直接書き換え
自身・継承されている要素

styleプロパティの書き換えの方がclassの書き換えより速い。でも汚い。

Webkitを自分でビルドしてdebug出力すれば再計算の起こったタイミングも調べられますよ。

  • レイアウトの計算

激しく重い
先祖要素も考えないといけないから

プロファイラ

何が重いとかより何度も何度も呼ばれてCPU時間を食ってる所をチューニング
JUIでもあった話(測りたい部分を適当な名前を付けた関数のその場定義&呼び出し)


ただ闇雲にチューニングするのは辞めよう
ご利用は計画的に

Q&A

  • 基本的にフラグが経ってる範囲と取得をした範囲が重なっている所のみだが、offsetWidth Hieghtはレイアウトの再計算も行われる
  • 理論上CSSチューニングも可能みたいな話も
  • Webkit速い(コンポーネントの通信とかレイアウト計算とか)
  • 勉強の優先順位：1:ソース読む、2:計測する、3:ドキュメント読む
  • WebkitのIDLを読むだけでも勉強になるよ