ブラウザエンジン先端観測会 #1

azu @azu_re

こないだWebKitコミッターになった #browser_gazer

タイムテーブルbot @event_timetable

■ ----- 16:00 CSS JIT / @Constellation atnd.org/events/52121 #browser_gazer

publichtml @publichtml

CSS JIT の話〜 #browser_gazer

kyo_ago @kyo_ago

ご注文はCSS JITです #browser_gazer

azu @azu_re

- CSSセレクタはものすごい回数が実行される - この要素にはこのスタイルを当てるというだけでも多い - QuerySelectorでも大量に行われる #browser_gazer

kyo_ago @kyo_ago

「.rabbit.house { ... }」 #browser_gazer

azu @azu_re

`.rabitt .house` というのだけでも大量の要素に対してやっていく必要がある #browser_gazer

ラーメン大好きKENZさん @KENZ_gelsoft

こんなnaiveな実装でいいのかで実際に動くのがC++のヤバいところ #browser_gazer

azu @azu_re

- QuerySelectorの実装 - rootから全ての要素を列挙する - 一個一個セレクタにマッチするかどうかを確認(C++動くの凄い - マッチしたものを返す #browser_gazer

:tetsuharu @saneyuki_s

こんな感じなんで、parallelにやりたいという希求あるんですよ ##browser_gazer

publichtml @publichtml

「こんなナイーブな(総当りの)実装で動くなんてC++すごい」 #browser_gazer

USBケーブル整理 @sys9kdr

class="rabbit house"よりclass="rabbit-house"がいいのではと思った #browser_gazer

kyo_ago @kyo_ago

「対象要素以下の全要素を列挙して、指定セレクタに一致するかどうかを全てチェックする。C++やばい」 #browser_gazer

azu @azu_re

あるセレクタが、与えられた要素にマッチするかを返すpredicateの高速化 #browser_gazer

:tetsuharu @saneyuki_s

確か、ブラウザの高速化に関する論文（Servoでも引用されてる）で、計測した結果、処理時間の20%弱がCSS selector matchingに要されてるという研究結果があったはず #browser_gazer

anatoo @anatoo

「querySelector、こんなナイーブな実装でいいのか」#browser_gazer

眼力 玉壱號 @objectxplosive

オーダー下げる様な方法は無いのかのぉ #browser_gazer

publichtml @publichtml

「セレクタの評価は(セレクタを書き下した表記の)右から左にやる」 #browser_gazer

USBケーブル整理 @sys9kdr

セレクタは右から左、有名な話だ。 #browser_gazer

azu @azu_re

- ~や+は関係性を示すもの(combinator) - div 単純な子孫(simple) - => 合わせてcompound selector #browser_gazer

kyo_ago @kyo_ago

右から評価するのって、基本的に「DOMに対してセレクターが一致するか」って評価方法を取るからかなー #browser_gazer

:tetsuharu @saneyuki_s

.@Constellation せんせ、ここらへんの調査結果で、ServoのSelector matchが最適化全然やってないのでコミットチャンスでpull req出してきた #browser_gazer

azu @azu_re

セレクタのマッチを確認して行った時に、間違ったマッチが起きた時にバックトラッキングをする #browser_gazer

anatoo @anatoo

CSSセレクタにマッチしているかどうかの処理時にルールとDOMツリーに酔ってはバックトラック必要になる #browser_gazer

azu @azu_re

マッチに失敗した時、次にマッチを再開するときにマッチの候補は少なくなるはず #browser_gazer