CSS matching is one of the more resource-intensive parts of the computation the browsers do; the given implementation is very instructive for understanding the algorithm, but would be too slow for any nontrivial page. The total possible number of comparisons is basically {number of rules} * {number of elements}, which can be extremely high, and avoiding this is quite important.
Interesting. So is that typically the reason why pages with large number of elements are so slow? I had always assumed it was the HTML elements themselves, but could the bottleneck here sometimes be the CSS matching of those elements?
Also, if I'm not mistaken, I believe that Servo (which the author of this post works on at Mozilla) is attempting some novel parallel CSS matching using Rust's support for parallelism/concurrency.
I am reminded of how IE uses a single integer to identify each CSS rule: http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164...