New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 599833 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
NOT IN USE
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Slow style recalc when many shadow trees have ::slotted rules

Reported by r...@opera.com, Apr 1 2016

Issue description

See attached demo.

The number of StyleResolver::m_treeBoundaryCrossingScopes are typically quite big (for polymer v0 apps, often in the hundreds) and it takes a lot of time traversing and matching rules for every one of them for every element.

For documents without v0 components, we can just walk the assignedSlot chain instead.

 
slotted.html
1.9 KB View Download
Project Member

Comment 1 by bugdroid1@chromium.org, Apr 4 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/34d768eb8c2c2bdd8e9cd259a0661b31d5f4c303

commit 34d768eb8c2c2bdd8e9cd259a0661b31d5f4c303
Author: rune <rune@opera.com>
Date: Mon Apr 04 08:34:50 2016

Fixed ::slotted performance in pure v1 shadow documents.

Instead of traversing all m_treeBoundaryCrossingScopes matching rules
from other scopes, just walk the assignedSlot() chain for resolvers.
This makes rule matching a lot cheaper since quite a lot of components
have tree boundary crossing rules in practice (polymer apps using v0
typically have hundreds of such scopes).

The assumption here is that the assignedSlot chain most of the time
will be quite short and/or cheap to walk.

Introducing a flag set in StyleEngine if there ever exists a v0 shadow
tree to fall back to traversing m_treeBoundaryCrossingScopes when
necessary.

For the slotted.html demo in  crbug.com/599833 , the full recalc with
~4000 elements goes from ~800ms to ~40ms with this change when each
shadow tree has a ::slotted rule. No substantial regression for the
case without ::slotted rules.

Added a test for /deep/ being used a descendant combinator in a
document without shadow trees, as I feared I might have broken that and
I couldn't find any existing tests for it.

For later, we may choose to never collect m_treeBoundaryCrossingScopes
for pure v1 documents, but that means we would have to recreate that
collection once we add a v0 shadow to the document.

R=kochi@chromium.org,hayato@chromium.org,dglazkov@chromium.org
BUG= 599833 

Review URL: https://codereview.chromium.org/1853713002

Cr-Commit-Position: refs/heads/master@{#384867}

[add] https://crrev.com/34d768eb8c2c2bdd8e9cd259a0661b31d5f4c303/third_party/WebKit/LayoutTests/fast/dom/shadow/apply-deep-in-document-scope-expected.txt
[add] https://crrev.com/34d768eb8c2c2bdd8e9cd259a0661b31d5f4c303/third_party/WebKit/LayoutTests/fast/dom/shadow/apply-deep-in-document-scope.html
[modify] https://crrev.com/34d768eb8c2c2bdd8e9cd259a0661b31d5f4c303/third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp
[modify] https://crrev.com/34d768eb8c2c2bdd8e9cd259a0661b31d5f4c303/third_party/WebKit/Source/core/dom/StyleEngine.cpp
[modify] https://crrev.com/34d768eb8c2c2bdd8e9cd259a0661b31d5f4c303/third_party/WebKit/Source/core/dom/StyleEngine.h

Comment 2 by r...@opera.com, Apr 4 2016

Status: Fixed (was: Started)

Sign in to add a comment