New issue
Advanced search Search tips

Issue 873798 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Sep 17
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Task

Blocking:
issue 835484
issue 873794


Participants' hotlists:
layoutng


Sign in to add a comment

[LayoutNG] Inline fragment traversal is slow

Project Member Reported by e...@chromium.org, Aug 13

Issue description

When loading the single-page HTML5 spec 50% of the layout time (and over 12% of all time_ is spent in NGPhysicalFragmentCollectorBase::VisitChildren. Allocation only accounts for a small fraction of that.

(see center of lower part of attached profile)
 
profile001.svg
153 KB Download
Blocking: 873794
Components: Blink>Layout
Summary: [LayoutNG] Inline fragment traversal is slow (was: [LayoutNG] Inline fragment collection is slow)
More importantly, we really shouldn't have to traverse the inlines at all to determine the layer position (UpdateLayerPositions) given that fragments have resolved physical coordinates.

Project Member

Comment 3 by bugdroid1@chromium.org, Aug 16

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

commit ad3078c836910d696c0e783e65b9245804f4d043
Author: Xiaocheng Hu <xiaochengh@chromium.org>
Date: Thu Aug 16 02:08:15 2018

[LayoutNG] Avoid inline fragment traversal on self-painting inlines

NGInlineFragmentTraversal::SelfFragmentsOf() traverses the entire
inline formatting context's fragment tree to find fragments of a
certain layout object, which is basically unnecessary since we can
locate the paint fragments directly. The only exception is culled
inline, where the layout object doesn't have its own fragments, in
which case we still need to traverse the fragment tree.

As performance optimization, this patch changes SelfFragmentsOf() to
find paint fragments directly, unless the given layout object can be
a culled inline.

With this patch, the time spent on SelfFragmentsOf() when rendering
the single-page HTML5 spec becomes negligible.

Bug:  873798 
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Id4a9e5a8a8e416e9757916e5ae9cf589c4660688
Reviewed-on: https://chromium-review.googlesource.com/1173725
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583499}
[modify] https://crrev.com/ad3078c836910d696c0e783e65b9245804f4d043/third_party/blink/renderer/core/layout/ng/inline/ng_inline_fragment_traversal.cc
[modify] https://crrev.com/ad3078c836910d696c0e783e65b9245804f4d043/third_party/blink/renderer/core/layout/ng/inline/ng_inline_fragment_traversal.h

Status: Fixed (was: Assigned)
Cc: atotic@chromium.org
Thank you Xiaocheng!

Down to 10% of the total layout time now (from 50%), the remaining time all seem to be coming from NGOutlineUtils::CollectDecendandOutlines.
Cc: -atotic@chromium.org xiaoche...@chromium.org
Owner: atotic@chromium.org
Status: Assigned (was: Fixed)
Reassigned to atotic@ as per #5...
Blocking: 835484
Status: Fixed (was: Assigned)
NGOutlineUtils::CollectDecendandOutlines has been deleted, and should no longer cause performance problems.
Status: Verified (was: Fixed)
\o/

Sign in to add a comment