[webkit-dev] Parallel CSS styling

[Roland Steiner]

On Wed, Jun 8, 2011 at 7:54 AM, Ojan Vafai <ojan at chromium.org> wrote:

> However, many of the performance improvements we can make to the
> single-threaded approach are limited in scope or have other trade-offs. For
> example, if I understand https://bugs.webkit.org/show_bug.cgi?id=49876
>  correctly, it only applies during parsing and uses 16 more bytes per
> RuleData. On some sites (e.g. gmail) that have >30k RuleDatas, that's a
> ~500k memory hit without much performance benefit. It's a great change for
> some sites, but it's a significant cost for others.
>

The point of trade-offs is of course very valid. But rummaging around that
part of the code myself, that particular linked patch should actually save
quite a bit of matching time: it does a quick'n'dirty comparison against a
bloom filter (comparing hashes of IDs/classes/tags of selector parts vs.
hashes of stuff we encountered in ancestors) to quickly weed out selectors
that cannot possibly match - not all of them, but it should be a significant
subset of them.

As another possible avenue of improvements I wondered why selectors aren't
stored in a Trie data structure. In this way we could 1.) quickly discard
whole sub-branches of non-matching selectors on bottom-up matching, and 2.)
perhaps even keep track of sub-sets of potentially matching selectors during
tree-recursion in a top-down fashion.


Cheers,

- Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110608/50c50b49/attachment.html>