Enabling StyleSharing for a limited set of pages

[Naina Raisinghani]

Hi everyone, 

I am transcribing a discussion that some folks had while I was visiting some Blink engineers in Mountain View (they are cced). 

We can potentially enable StyleSharing for a limited set of pages, by restricting it to pages that only use simple selectors (IDs, Classes, Tags, Attributes, ::before and ::after nodes). Since this information is local to a node we don't have to incur maintenance cost of editing the StyleSharing code each time we change around how Style resolution happens. 

The idea is, if we find that the page only uses simple selectors we can flip a bit on Document and cache all nodes that map to an ID, class, etc on the Document too. If the page has a more complex selector, we can clear this cache. The lookup should be a relatively free operation.

I have added UseCounters to try to detect how many pages in the wild would meet this criteria of simple selectors. 

Do folks have any thoughts on this idea?

[Ojan Vafai]

On Sun, Nov 5, 2017 at 10:07 PM Naina Raisinghani <nai...@chromium.org> wrote:

Hi everyone, 

I am transcribing a discussion that some folks had while I was visiting some Blink engineers in Mountain View (they are cced). 

We can potentially enable StyleSharing for a limited set of pages, by restricting it to pages that only use simple selectors (IDs, Classes, Tags, Attributes, ::before and ::after nodes). Since this information is local to a node we don't have to incur maintenance cost of editing the StyleSharing code each time we change around how Style resolution happens.  

The idea is, if we find that the page only uses simple selectors we can flip a bit on Document and cache all nodes that map to an ID, class, etc on the Document too. If the page has a more complex selector, we can clear this cache. The lookup should be a relatively free operation.

In addition to being lower maintenance and performance overhead than the previous style sharing, we would share considerably more since two elements in totally different parts of the tree with the same id/class/etc would share. So it should also have much higher performance benefit than the previous style sharing as well.

[Darren Shen]

This is a really interesting idea. If the performance gains are large, then it might encourage websites to eliminate complex selectors too. Personally I don't think many websites will be eligible for this optimisation :P, but that's probably just me being pessimistic, so it'd be good to see the actual data when we get it.

--
You received this message because you are subscribed to the Google Groups "style-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to style-dev+...@chromium.org.
To post to this group, send email to styl...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/style-dev/CANMdWTv-dxpVwAm8mZAktWAnh5bpok-wi9bN_VLKSzK3BxNnFQ%40mail.gmail.com.

[Douglas Stockwell]

A few cons/questions from my perspective: 

1. It doesn't seem as simple as stated here, e.g. these styles that might otherwise be shared could diverge due to inherited CSS variables.

2. UA sheets are not made up of only simple selectors, so I'm not sure there can be any pages that use only simple selectors?

3. The optimization seems weak. These sharing cases would already be covered by the matched property cache. I think we'll still end up evaluating even the simple selectors, what are we saving?

- Doug

To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/style-dev/CAMO7KM-cX%2BHwGbqHN-ENBy2Mop0hYyqbDtzyq%3DShkSt3ufj%3DEA%40mail.gmail.com.

[Naina Raisinghani]

On Mon, Nov 6, 2017 at 2:43 PM Douglas Stockwell <dstoc...@chromium.org> wrote:

A few cons/questions from my perspective: 

1. It doesn't seem as simple as stated here, e.g. these styles that might otherwise be shared could diverge due to inherited CSS variables.

 

Didn't think of this at all. I didn't think about custom properties. 

2. UA sheets are not made up of only simple selectors, so I'm not sure there can be any pages that use only simple selectors?

I think that's a fair comparison to make, but yeah you are right we might be hard pressed to find a site that matches the case at hand.

To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/style-dev/CAMs_2YUmBU4yUwguy_4fC%2BmQpazoQYD%3DCx5BUKqC-vrgrjV%3D-g%40mail.gmail.com.

[Ojan Vafai]

On Wed, Nov 8, 2017 at 11:35 AM Naina Raisinghani <nai...@google.com> wrote:

On Mon, Nov 6, 2017 at 2:43 PM Douglas Stockwell <dstoc...@chromium.org> wrote:

A few cons/questions from my perspective: 

1. It doesn't seem as simple as stated here, e.g. these styles that might otherwise be shared could diverge due to inherited CSS variables.

 

Didn't think of this at all. I didn't think about custom properties.

Hmmm...yeah. Inheritance makes this harder. We've already move some properties over to pushing down inherited property values instead of forcing a subtree recalc, right? If we do that for all inherited properties/variables, then this optimization would still work. Also, it would generally be a performance improvement to get rid of subtree recalcs so is a change worth doing anyways?

 

2. UA sheets are not made up of only simple selectors, so I'm not sure there can be any pages that use only simple selectors?

I think that's a fair comparison to make, but yeah you are right we might be hard pressed to find a site that matches the case at hand.

Aside from the UA sheet (which, we can theoretically fix), I thought there wouldn't be much content for this either until I talked to framework authors. They claim that modern preprocessors often only output simple selectors, so a lot of modern PWA content should comply with this.

Even if it's not a large percentage of sites, if we can give people making new PWAs a way to get a significant performance boost, it seems worth it.

  

3. The optimization seems weak. These sharing cases would already be covered by the matched property cache. I think we'll still end up evaluating even the simple selectors, what are we saving?

Why would we evaluate the simple selectors? You'd avoid all selector matching when sharing, no? This was a huge win in the Sky prototype. That's not apples to apples, but I'd be surprised if the huge win didn't at least somewhat translate.