On Wed, Jun 8, 2011 at 7:54 AM, Ojan Vafai <[email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
