On Thu, Apr 18, 2013 at 6:27 PM, Peter Moulder <peter.moulder@monash.edu> wrote: > When the change to :matches specificity was proposed, I'd noticed that > the change has a slight performance impact on matching because we now need > to find the maximum-specificity sub-selector instead of just the existence > of a matching sub-selector; but I hadn't noticed the related performance > impact on combinator chains, i.e. that a selector like > > :matches(...) :matches(...) :matches(...) p > > or > > :matches(...) ~ :matches(...) ~ :matches(...) ~ p > > can no longer be content to find the existence of three matching nodes, > it now needs (in general) to find the most specific combination of > matching nodes. > > This seems to be a more intrusive a change than I'd previously thought was > involved: it looks like it can in some cases become quite a bit slower than > with the previous max-of-arguments behaviour (especially with deep trees > and long chains of combinators), and requires more implementation work > because it introduces a type of search [or a cartesion product expansion] > that wasn't previously required in CSS. Ultimately, it's *exactly* as bad as unfolding the :matches() out of the selector. Yes, it's combinatorial in complexity. But that's the whole point of :matches() - to hide that complexity in an easy-to-write form. ~TJReceived on Friday, 19 April 2013 01:37:52 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:28 UTC