[Feature Request] Style Recalculation: Show selectors + time taken

[Jacob G]

Opera Dragonfly had this: https://twitter.com/kdzwinel/status/860631991758270466

[Ashley Gullen]

Layout is the #1 performance problem we have in our PWA Construct 3 (editor.construct.net). *Anything* that tells us more about what made layout take so long would be incredibly helpful. Seeing an opaque 40ms "Layout" block is usually a performance dead-end.

[RaphaelDDL]

That looks neat!

We normally know the rules for css selectors and yada yada but knowing exactly how much time a selector took (and it's properties) and how many items were affected by it is awesome, opens possibilities to make them perform better.

I'm totally in favor of that.

[PhistucK]

Generally, for feature requests, you can search crbug.com for an existing issue for this feature request and star it. If you cannot find one, you can use the "New issue" link at crbug.com to file a new one.

(If you do find one, do not add comments like "+1" or "me, too", it only hinders the development and it does not make the engineers implement the feature more quickly.)

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/11f77df3-4355-4e5e-8440-178881e333bd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jacob G]

I've opened a new issue: https://bugs.chromium.org/p/chromium/issues/detail?id=719877 (it has "Type: Bug", I couldn't find a feature request flag).

@everyone: Please star this issue and if you have any, add helpful comments :)

Am Dienstag, 9. Mai 2017 06:24:44 UTC+2 schrieb PhistucK:

Generally, for feature requests, you can search crbug.com for an existing issue for this feature request and star it. If you cannot find one, you can use the "New issue" link at crbug.com to file a new one.

(If you do find one, do not add comments like "+1" or "me, too", it only hinders the development and it does not make the engineers implement the feature more quickly.)

☆PhistucK

On Tue, May 9, 2017 at 12:11 AM, RaphaelDDL <rapha...@gmail.com> wrote:

That looks neat!

We normally know the rules for css selectors and yada yada but knowing exactly how much time a selector took (and it's properties) and how many items were affected by it is awesome, opens possibilities to make them perform better.

I'm totally in favor of that.

On Monday, May 8, 2017 at 3:33:49 PM UTC-3, Jacob G wrote:

Opera Dragonfly had this: https://twitter.com/kdzwinel/status/860631991758270466

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.

[Stephan Schmitz]

Would love to see this implemented. +1

[Kayce Basques]

Generally, for feature requests, you can search crbug.com for an existing issue for this feature request and star it. If you cannot find one, you can use the "New issue" link at crbug.com to file a new one.

Judging from recent replies on this mailing list from a few of the DevTools engineers, they prefer for the community to discuss ideas here, and then open a FR once it becomes clear that there's a strong interest for it

So discuss away. Ashley's reply about how it's useful for their app and how DevTools is currently lacking was particularly helpful 

[PhistucK]

Of course it is a good place, but having it logged can help trigger an actual action on the subject (and people can star it).

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/f0241d0c-c90c-40f9-b42e-896d15871e0a%40googlegroups.com.

[Harry Roberts]

Joining the thread to register my interest (and that of everyone I’ve mentioned this to). Anything else I can do to gather support?

On Tuesday, May 9, 2017 at 6:05:04 PM UTC+1, PhistucK wrote:

Of course it is a good place, but having it logged can help trigger an actual action on the subject (and people can star it).

☆PhistucK

[Illia Gaisiuk]

I think it's a cool feature to be implemented in Chrome. +1

[Viktor Tkachenko]

wow, its amazing and can help us to increasing performance .. 

it would be cool if we have it 

понедельник, 8 мая 2017 г., 21:33:49 UTC+3 пользователь Jacob G написал:

[Jørgen Landsnes]

+1 This would effectively reveal code smells that mostly are hard to find.

[Pavel L.]

+1

On Monday, May 8, 2017 at 9:33:49 PM UTC+3, Jacob G wrote:

[PhistucK]

Be sure to also show your interest by starring the feature request.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chrome DevTools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/b480466d-6263-42f1-969f-584315b757a9%40googlegroups.com.

[Pavel L.]

Done. Thanks

[István Csáki]

+1

[Aldíbier Morales]

+1

[Sam Zwaaij]

+ 1

Op maandag 8 mei 2017 20:33:49 UTC+2 schreef Jacob G:

[Paweł Bystrzan]

+ 1

[Paul Irish]

Hiya.

Please don't +1 this thread. Starring https://crbug.com/719877 is equivalent.

As for the feature request, we have rarely found circumstances where costly selectors are a bottleneck to performance. If you have a trace where Style Recalc is a dominant and significant cost, you can email it to me privately.

--

You received this message because you are subscribed to the Google Groups "Chrome DevTools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/43468e4d-4a4e-458e-a156-66124818317d%40googlegroups.com.

[RaphaelDDL]

Just my 2cent regarding real usecases:

I'd imagine for most of cases, the info would be mostly used as "curiosity".

A real use case, imho, would be niche, like browser games devs and/or super-heavy SPAs. 

For example, back 2012, when CSS3 was still starting to show up, it was known that some css3 properties were dragging animation frame rate down on older iPads, like box-shadow, border-radius and such. Here's a blog post from Cubiq (Matteo Spinelli), where I first learned about the css performance issues and started researching more about it.

I guess, back then, knowing that the selector `#a.b > c` took more time than the others could have hinted him as to the performance issues not only by the selector itself, but within the properties the selector contains.

Nowdays the browser performance is lot better (as the devices), but when we get new experimental css properties, that might come handy.

[RaphaelDDL]

Apologies: Here's the correct blog post: http://cubiq.org/webkit-weird-box-shadow-bug-with-fix 

The post above has the url with https, but seems his website does not have it :P

[Paul Irish]

On Wed, Jun 27, 2018 at 2:04 PM, RaphaelDDL <rapha...@gmail.com> wrote:

Just my 2cent regarding real usecases:

I'd imagine for most of cases, the info would be mostly used as "curiosity".

Understood. But as performance tool developers we want to help developers avoid premature optimization and focus on the primary bottlenecks.

So this is why I'm incredibly skeptical of css selector cost being a worthwhile time investment for either of us. :)

 

For example, back 2012, when CSS3 was still starting to show up, it was known that some css3 properties were dragging animation frame rate down on older iPads, like box-shadow, border-radius and such. Here's a blog post from Cubiq (Matteo Spinelli), where I first learned about the css performance issues and started researching more about it.

I guess, back then, knowing that the selector `#a.b > c` took more time than the others could have hinted him as to the performance issues not only by the selector itself, but within the properties the selector contains.

Interesting case. 

Unfortunately such a profiler wouldn't be able to help in this situation.  Here's a quick description of the rendering pipeline.

• Style Recalculation: match all selectors in the stylesheets against the current DOM, then determine the computed style for every element.
• Layout: Figure out where all the elements are geometrically placed, based on the style information we know.
• Main-thread Paint: Determine what draw commands we'll use to render everything, including handling borders, shadows, etc
• Rasterize Paint: Run all these draw commands. 

The rasterization step is where all the cost of box-shadow, border-radius, etc lies. 

And unfortunately the browser only knows draw commands at this point, the concept of "DOM nodes" isn't present at this point in the pipeline. And so we can't necessarily track it back to a specific style rule, selector, or property.

The "advanced paint instrumentation" in devtools Performance panel can help here: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#paint-profiler

It'll at least try to quantify the cost of each draw call. And you can see what changed. See 13s into this video: https://twitter.com/paul_irish/status/991395746078322688 

But the best a "selector profiler" could do is only quantify how long it took us to match `#a.b > c` to any current DOM nodes. This is would be roughly equivalent to running querySelectorAll. So you can write your own selector profiler within the page. Seems like a fun ill project. :)

Cheers

[Jacob G]

Hi Paul, thank you for the explanation.

A little off-topic, but since this is a feature request anyway, maybe we can change it a little. 

Most sites that I profile spend the most time into drawing layers. The Dev Tools at the moment are pretty unhelpful on how to optimize that step. 

The `contain` prop pretty much reduces style calc to almost non existent, however I still haven't figured out how to optimize the layer step.

In my experience it's sometimes even faster to only have one layer; I can't explain why the updating layers step takes longer if there are more layers, even when those layers aren't changed. So that could be an addition for either the layers tab or the advanced painting profile. 

--
You received this message because you are subscribed to a topic in the Google Groups "Chrome DevTools" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-chrome-developer-tools/u5faSywBmFE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CAK-PPf12-1g5n6mO4O%2BQHxg-yOAcRTZm6rFS8g37NOiwSKx%3DZw%40mail.gmail.com.

[tugcan....@cybersoft.com.tr]

[Andrei Voicu]

+1

On Monday, May 8, 2017 at 9:33:49 PM UTC+3, Jacob G wrote: