Hacker News Reader

Comment by pcwalton | Hacker News Reader

Just asked Emilio on IRC for some quick numbers.

emilio: pcwalton: wrt gecko we have stuff like https://bugzilla.mozilla.org/show_bug.cgi?id=1342220#c25 and similar

emilio: pcwalton: there's also the tp6 numbers, though those also measure CSS parsing and other stuff that isn't the style engine per se

pcwalton: emilio: our tp6 numbers are improved over Gecko at this point, yes? :)

emilio: pcwalton: amazon by a huge amount, facebook not yet I believe, but patches are on the queue that should make it turn around :)

emilio: pcwalton: happy to talk with mjs about impl details too, if he wants. I know a bit of WK stuff too :)

View on HN

This is an easy benchmark for rejecting a lot of selectors:

http://bholley.net/testcases/style-perf-tests/perf-reftest/b...

Firefox with STYLO_THREADS=1 gets about 160ms on my machine, which is basically parity with safari and chrome. With the parallelism, Firefox gets 40ms. :-)

You can also simulate sequential mode in recent nightlies by ctrl-clicking and loading the tab in the background (we disable parallelism for background loads).

Thanks, that is the kind of thing I was looking for (though a bit of a narrow test). Cool to hear that this gets a solid speedup from parallelism.

(for more context, Facebook has a very small style recalc time, so we're bottlenecked right now on the time it takes for us to parse CSS, and build the data structures for selector-matching and invalidation, and the patches on the queue are https://github.com/servo/servo/pull/18191)

Thanks for the pointer! Sadly, I couldn't find any concrete numbers or tests to run at that link.

I'm mildly interested in impl details. But I'm more interested in what it speeds up and how it was measured (ideally in a form where I could try my own old-to-new and cross-browser comparisons, but just numbers would be interesting too).

The STR for that bug are in comment 3, but I can try to get something better when I'm back home (on my phone now).

We get significant speed ups from parallelism and such on big doms over all during page load, but we also get speedups from dynamic change handling implementing smarter invalidation than Gecko, which basically restyles the whole subtree / every sibling if it finds a relevant combinator affected by a change.

WebKit does much better than Gecko for class and other attribute changes, at least for descendants, where you go down with the relevant selectors. Stylo's system is relatively similar, but doing selector matching ltr, and handling the same way state and id changes.

You can see components/style/invalidation/element in the servo repo for the relevant code in that regard.

Reply on news.ycombinator.com