As per provided CL by the user adding cbiesinger@ for more update on this issue.

cbiesinger@ - Could you please look in to this issue?

We have a repo with a node server that can serve up a page with the issue, but it's pretty far from a plunkr-sized demo. It's a very basic application with no Ajax requests. Due to the nature of the code, we'd likely need to do an invite for the repo directly to individuals. Let me know if that would be helpful and who to email.

 bug 595361  should help with some of the performance issues. But that's only in 53.0.2751.0. I can request a merge to 52.

In addition, if you use overflow: auto at all, then szager's fix in aff9f64394945f24400021fdec18dbd70eee3e14 should help.

Could you try Chrome Canary version 53.0.2759.0 or later and see if that helps you at all? If not, I can keep looking and see what I can do.

Sadly, we're still seeing the issues in the canary. We were able to find a workaround by removing height & width 100% from all the child containers where a parent already had it. 

"The structure of our application heavily uses flex box to provide support for nested paneling (something like this: https://plnkr.co/edit/gRUQfYdxtUFjZuSmbzBS?p=preview). The issue we eventually identified in our css was that we were taking a shortcut in our css and making every flex child also a flex container (with height/width set to 100%). Our solution was to more appropriately use flex box as intended and separate the flex container and child item styling and only apply the 100% height/width to the container."

If you want access to our small node demo application, it reliably reproduces the issue, but it's by no means a small amount of code.

Thanks -- if you could give me access to it, that would be great. I do have some more ideas on how to make this faster.

In the meantime I'm glad you found a workaround!

Did you get my email with the attached code?

I did not actually... what address did you send it to?

I sent it as a zip to the chromium.org address listed above

Oh that's weird... you used the full email address, right? (cbiesinger, not the one with the dots)

I'll resend when I get near my computer. It should have come from this
email address.

I still haven't received it :( Maybe try my email @gmail?

Nevermind, found it!

can you email from your address at that gmail address? I've got a smaller zip as well I'd like to have a chance to talk about the code without it showing up in this thread.

Ok, I emailed two more versions of the zip without
node_modules/bower_components. One is the old version with the issue, and
the other is the refactored version that works with 51+

*sigh*, the profile does show pretty terrible performance. *Half* time is spent in computePercentageLogicalHeight!! Almost all of that through the call to mainAxisLengthIsDefinite...

But even if I fix that, it's still crazy slow... looking more.

In fact, even if I disable the force-relayout-for-percentages code, this is still really slow. this is a mystery! still looking.

Hmm, bisect does point to percentages though:
You are probably looking for a change made after 388305 (known good), but no later than 388315 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/cf3b9c5368b230baf30a97e2ddfa4529fc1bb0e5..440b117bb10d5c7e195a26cf974ccbd5886948b0

Which contains:
0702247 [css-flexbox] More correctly implement percentage sizing by cbiesinger · 3 months ago

Ah, the problem is this call I added:
+    dirtyForLayoutFromPercentageHeightDescendants(layoutScope);

OK, I have fixes:
https://codereview.chromium.org/2056043002/
https://codereview.chromium.org/2128093003/

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

commit e31affc47d4167415327e54c48da086e9152ee10
Author: cbiesinger <cbiesinger@chromium.org>
Date: Thu Jul 07 03:05:43 2016

[css-flexbox] Don't over-invalidate flex items

dirtyForLayoutFromPercentageHeightDescendants invalidates too much. We already
have code to handle this case, so remove this call. We did have a bug in
that code though -- we do need to force layout on flex items even if did not
lay them out already: such percentages are only resolvable if the flexbox has
a definite height. However, whether the flexbox height is definite may have
changed since the last layout. So, we need to relayout in either case.

The similar code in applyStretchAlignment does not have this issue because
percentages in the cross axis can be resolved independent of whether the
flexbox height itself is definite.

This is covered by an existing test; the call to
dirtyForLayoutFromPercentageHeightDescendants was previously covering this case
but is slower.

This caused a massive performance regression (many minutes to lay out a
flexbox-based website instead of a few seconds).

TEST=css3/flexbox/definite-cross-sizes.html
BUG= 595361 , 617792 
R=dgrogan@chromium.org,eae@chromium.org

Review-Url: https://codereview.chromium.org/2128093003
Cr-Commit-Position: refs/heads/master@{#404056}

[modify] https://crrev.com/e31affc47d4167415327e54c48da086e9152ee10/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp

Your change meets the bar and is auto-approved for M53 (branch: 2785)

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 447be33eb6e7761a91cc6c40603ab23897233724
Author: Christian Biesinger <cbiesinger@chromium.org>
Date: Fri Jul 08 16:46:23 2016

[css-flexbox] Don't over-invalidate flex items

dirtyForLayoutFromPercentageHeightDescendants invalidates too much. We already
have code to handle this case, so remove this call. We did have a bug in
that code though -- we do need to force layout on flex items even if did not
lay them out already: such percentages are only resolvable if the flexbox has
a definite height. However, whether the flexbox height is definite may have
changed since the last layout. So, we need to relayout in either case.

The similar code in applyStretchAlignment does not have this issue because
percentages in the cross axis can be resolved independent of whether the
flexbox height itself is definite.

This is covered by an existing test; the call to
dirtyForLayoutFromPercentageHeightDescendants was previously covering this case
but is slower.

This caused a massive performance regression (many minutes to lay out a
flexbox-based website instead of a few seconds).

TEST=css3/flexbox/definite-cross-sizes.html
BUG= 595361 , 617792 
R=dgrogan@chromium.org,eae@chromium.org

Review-Url: https://codereview.chromium.org/2128093003
Cr-Commit-Position: refs/heads/master@{#404056}
(cherry picked from commit e31affc47d4167415327e54c48da086e9152ee10)

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

Cr-Commit-Position: refs/branch-heads/2743@{#599}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/447be33eb6e7761a91cc6c40603ab23897233724/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp

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

commit 291a41e2a82664720953ddc7bc6b3f4e86f07b83
Author: Christian Biesinger <cbiesinger@chromium.org>
Date: Fri Jul 08 16:52:02 2016

[css-flexbox] Don't over-invalidate flex items

dirtyForLayoutFromPercentageHeightDescendants invalidates too much. We already
have code to handle this case, so remove this call. We did have a bug in
that code though -- we do need to force layout on flex items even if did not
lay them out already: such percentages are only resolvable if the flexbox has
a definite height. However, whether the flexbox height is definite may have
changed since the last layout. So, we need to relayout in either case.

The similar code in applyStretchAlignment does not have this issue because
percentages in the cross axis can be resolved independent of whether the
flexbox height itself is definite.

This is covered by an existing test; the call to
dirtyForLayoutFromPercentageHeightDescendants was previously covering this case
but is slower.

This caused a massive performance regression (many minutes to lay out a
flexbox-based website instead of a few seconds).

TEST=css3/flexbox/definite-cross-sizes.html
BUG= 595361 , 617792 
R=dgrogan@chromium.org,eae@chromium.org

Review-Url: https://codereview.chromium.org/2128093003
Cr-Commit-Position: refs/heads/master@{#404056}
(cherry picked from commit e31affc47d4167415327e54c48da086e9152ee10)

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

Cr-Commit-Position: refs/branch-heads/2785@{#59}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/291a41e2a82664720953ddc7bc6b3f4e86f07b83/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp

Is this in the current Beta build?

It is in these builds:
  initially in 54.0.2791.0
  merged to 53.0.2785.11 (as 291a41e2a82664720953ddc7bc6b3f4e86f07b83)
  merged to 52.0.2743.71 (as 447be33eb6e7761a91cc6c40603ab23897233724)

I believe there has not yet been a beta release made at that version though. You could try canary for now.

However, note that there's a second patch coming soon that will help a bit more (still waiting for review).

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

commit 7f6ee2762d0e5617c17ad828d6353424ca59bacd
Author: cbiesinger <cbiesinger@chromium.org>
Date: Wed Jul 13 03:38:28 2016

[css-flexbox] Cache whether our main axis size is definite

This is an important performance optimization on pages
that have a lot of percentage-sized descendants of flexboxes.

TEST=n/a, no change in behavior
BUG= 617792 

Review-Url: https://codereview.chromium.org/2056043002
Cr-Commit-Position: refs/heads/master@{#404969}

[modify] https://crrev.com/7f6ee2762d0e5617c17ad828d6353424ca59bacd/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp
[modify] https://crrev.com/7f6ee2762d0e5617c17ad828d6353424ca59bacd/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.h

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

commit 7f6ee2762d0e5617c17ad828d6353424ca59bacd
Author: cbiesinger <cbiesinger@chromium.org>
Date: Wed Jul 13 03:38:28 2016

[css-flexbox] Cache whether our main axis size is definite

This is an important performance optimization on pages
that have a lot of percentage-sized descendants of flexboxes.

TEST=n/a, no change in behavior
BUG= 617792 

Review-Url: https://codereview.chromium.org/2056043002
Cr-Commit-Position: refs/heads/master@{#404969}

[modify] https://crrev.com/7f6ee2762d0e5617c17ad828d6353424ca59bacd/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp
[modify] https://crrev.com/7f6ee2762d0e5617c17ad828d6353424ca59bacd/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.h

Requesting merge approval for this new patch to 53 as well. Maybe not 52, I understand that release is pretty close and most of the performance benefit was in the first patch.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

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

commit c423bf24146b71a11c3a92932db591bcedeec13d
Author: Christian Biesinger <cbiesinger@chromium.org>
Date: Thu Jul 14 18:04:40 2016

[css-flexbox] Cache whether our main axis size is definite

This is an important performance optimization on pages
that have a lot of percentage-sized descendants of flexboxes.

TEST=n/a, no change in behavior
BUG= 617792 

Review-Url: https://codereview.chromium.org/2056043002
Cr-Commit-Position: refs/heads/master@{#404969}
(cherry picked from commit 7f6ee2762d0e5617c17ad828d6353424ca59bacd)

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

Cr-Commit-Position: refs/branch-heads/2785@{#118}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/c423bf24146b71a11c3a92932db591bcedeec13d/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp
[modify] https://crrev.com/c423bf24146b71a11c3a92932db591bcedeec13d/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.h

@csojka: Could you please have a look at the attached video and let us know if this is the correct procedure to repro this issue. 

Else, please provide us a sample JSFiddle/File to repro this issue from our end.

Thank you.

Deleted: 617792.mov 14.2 MB

617792.mov 14.2 MB Download

I sent an example to Christian Biesinger, but I will investigate if the HTML/css is the same as the video today. I assume he could verify as well.

No, the css/html in that plnkr will mitigate the change and was the source of our workaround solution. I don't have public code to demo the issue, but I can provide a project that does if you can send me an email.

I can't verify on an actual release because there is no Canary for Linux, and there have been no dev/beta releases with the fix. However, I have verified with my own builds that csojka's demo is now fast.

Based on comment#43 I am considering this as verified and the fix should be there in next M53 dev channel release soon.

 Issue 632372  has been merged into this issue.