« 雨天中止の巻 | メイン | マイペースな人になかなか恋人が出来ない5つの理由 »

2008年10月16日

JJUG Cross Community Conferenceに行ってきた

有意義でした。とりあえず、聞いたことをまとめたのを途中まで書いた。順次更新予定。

DOMパフォーマンスチューニング入門

amachangによるJavaScript講座。面白かった。私がテーブルをソートするスクリプトを自分で書いたのを使っていて、これを高速化したかったので、聞きにいった。

議題
  • JavaScriptが遅いんじゃなくてDOMが遅いんだよ
  • DOMが遅いのは、ブラウザのレンダラ側の問題だよ
DOM要素へのプロパティアクセスを意識する

style等でDOM要素のプロパティを見に行く場合、いちいちブラウザ側と通信が発生する。

elm.style.background = "#FFF";
elm.style.width      = "500px";

よりも、

var elmstyle        = elm.style;
elmstyle.background = "#FFF";
elmstyle.width      = "500px";

の方が速い。ドットシンタックスの数を数えると分かりやすい。(上だと4つ、下だと3つ)

ただし、これは無視できるほどのオーバーヘッドに過ぎない。特にFirefoxの場合。IEだと少しは高速化できる。

スタイルの再計算を意識する

JavaScriptでは、変更可能性のあるDOM要素に変更フラグを立てておいて、JavaScript側の処理が終わってから、ブラウザ側でスタイルの再計算、レイアウトの再計算を行う。JavaScriptの処理時間を計るだけじゃベンチマークが取れない!

スタイルの再計算は基本的にはJavaScript側の処理が終わってから行われる。ただし、変更フラグを立てた後、要素のスタイルを再取得しにいった場合は、その場で再計算が行われる。(そうしないとその時点での要素の幅等が出てこないから当たり前っちゃあ当たり前)

なので、どっかの要素に変更フラグを立てた後に、offsetWidthかなんかで要素のスタイルを取得しにいき、また、その要素に変更をかけたりすると、スタイルの再計算が2度走る事になるので、効率が悪い。JavaScript側の処理が終わってから一括してスタイルの再計算がされるようにコードの順番を意識する。

また、変更フラグは、「スタイルを変更したDOM要素」「そのDOM要素のCSSスタイルを継承することによって変更されうる要素」に立つ。

なので、なるべくDOMを掘ってから、スタイルの変更を当てた方が、高速化できる。

レイアウトの再計算

ここが大きなボトルネック。あまり高速化手法は無いが、新たな要素をposition:absoluteで置いてしまうってのは有り。

質疑応答

Q.DOMを高速化する上で、シンプルでクリーンなCSSを書いておくのは有効?そのためのノウハウみたいなものはあるか?(ちなみに私がした質問)
A.そのあたりは出来れば良いのかもしれないけど、分業の問題なので、CSSを書く人側でそういうことまで意識しておく必要は無いんじゃないか。CSS書く人と一緒に仕事をすることが少ない(自分で書く)のでよく分からない。

Q.どのブラウザのJavaScriptが高速だと感じるか
A.圧倒的にWebKit。JavaScriptの処理だけじゃなく、レンダリングも速い。

Q.どうやって技術を学習しているか
A.ソースを読んでいる。WebKitのソースとか別にそんなに難しくない(!!?)。WebKitのソースは拡張子が[idl]のファイルだけを読むだけでも勉強になる。

ギークなお姉さんができるまで

べにぢょさんが「ギーク」をフラットに発音していたのが、気になった。ああ、この界隈では一般名詞化しているんだなぁと思いました。私は後ろを下げて読んでた。

*参考 平板読みは間違い!? 「B'z」の正しい呼び方って?

べにぢょさんはポジティブ100%な人で全然他人の否定をしなさそう。その辺が安心感とか、人気につながってるんだろうなぁとか思いました。

最初は、purpurinが話しすぎかなぁとか思いましたが、最後の方は、purpurinさんの話をもう少し聞きたいなぁとか思った。マークアップエンジニアとしてちゃんとお金を稼げてる人みたいだったから。

purpurinさんが言ってた、

「最初はホームページ作りたかったんだけど、CSSという手段に惚れた」

って言葉はよく分かるなぁと同意。

それと、ひがやすを氏が突っ込んでた

「Webプログラマは(CSSの)スペックは分かるけどデザインは出来ない人が多い」

て言葉も全くだと思いました。なんか、Webプログラマーとデザイナーが交流できるイベントみたいなものの企画みたいな話にもなっていて、期待。

「JavaからRubyへ」アンド・ナウ

面白かった。よくまとまっているエントリーは多くありそうなので、個人的に以下面白いと思った発言を羅列。

  • Webで使われているPHPの代替手段としてのRubyと言う本は多く出ていたが、エンタープライズ目的のJavaからRubyへの移行というニッチが残っていたので「From Java to Ruby」を翻訳した。
  • JavaはCOBOL化している。良い意味で
  • DHHはOO厨(賛辞)
  • 「達人プログラマー」を読め

てことで、3つのセッションのみ参加したが、その次のセッションもペアプロとかしたみたいで、残れば良かったとか思いました。

投稿者 Songmu : 2008年10月16日 23:34