All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=630448

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6qi2lgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgquX-1AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6raI2ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6rjR_QkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqubO2QkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6ubUvAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgmszbowkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgmtzLqQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg2qi3tgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6oO0rwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgmtzfuAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgquLi0gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6qGi6wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6pee-QkM


Bot(s) for this bug's original alert(s):

chromium-rel-mac-retina
chromium-rel-mac10
chromium-rel-mac11
chromium-rel-win7-dual
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
chromium-rel-win7-x64-dual
linux-release

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9006486223942508704

=== Auto-CCing suspected CL author jfernandez@igalia.com ===

Hi jfernandez@igalia.com, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : [CSS Grid Layout] Handle alignment with orthogonal flows
Author  : jfernandez
Commit description:
  
Now that grid sizing and positioning issues wrt orthogonal flows have
been clarified in the last spec draft, we can adapt now our alignment
logic to work with orthogonal flows.

Even though basic alignment would work with orthogonal flows with
this patch, we still doesn't allow stretching in that case. I'll provide a
patch for that feature since it's a complex logic and better have an
isolated change.

BUG= 556171 ,  445742 ,  376823 ,  249451 

Review-Url: https://codereview.chromium.org/842193004
Cr-Commit-Position: refs/heads/master@{#406557}
Commit  : af5c2165bff01ba473fe28d31dd2a15d789ef08e
Date    : Wed Jul 20 15:09:08 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@406556  1386.15  7.4495   5  good
chromium@406557  1229.99  5.79043  5  bad    <--

Bisect job ran on: linux_perf_bisect
Bug ID: 630448

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.layout
Test Metric: fixed-grid-lots-of-stretched-data/fixed-grid-lots-of-stretched-data
Relative Change: 11.27%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6602
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9006486223942508704


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5886867182977024

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

I'll take a look.

I can confirm the regression and its root cause, which is indeed caused by my patch. 

I'm already working on a fix.

Great, thanks so much jfernandez!

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

commit 2cf9f05031414616d3d1eb1e5ffa5013e396d61b
Author: jfernandez <jfernandez@igalia.com>
Date: Tue Jul 26 10:55:53 2016

[css-grid] Avoid the HashMap for the override containing block size

The change made in r406557 caused a 12% regression on the grid layout
performance tests. The root cause is that as part of the changes
required to implement the orthogonal flows support we decided to use
physical directions to determine whether a grid item overflows its
grid area or not. Since we store the logical sizes in a HashMap, we
implemented some utility methods that, based on the grid container's
writing mode, retrieve the stored width or height from the HashMap.

Since the previous logic was reusing the already computed logical
value, the change introduced a considerable performance regression.

This patch address the issue by removing the utility methods and
determine the physical sizes directly inside the layout logic.

BUG= 630448 

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

[modify] https://crrev.com/2cf9f05031414616d3d1eb1e5ffa5013e396d61b/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/2cf9f05031414616d3d1eb1e5ffa5013e396d61b/third_party/WebKit/Source/core/layout/LayoutBox.h
[modify] https://crrev.com/2cf9f05031414616d3d1eb1e5ffa5013e396d61b/third_party/WebKit/Source/core/layout/LayoutGrid.cpp
[modify] https://crrev.com/2cf9f05031414616d3d1eb1e5ffa5013e396d61b/third_party/WebKit/Source/core/layout/LayoutGrid.h

The change in r407762 should have fixed this issue. Please, verify and reopen it otherwise.

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

commit 04a768e5991c6e4d0967320e8b563930769439c9
Author: robliao <robliao@chromium.org>
Date: Tue Jul 26 23:38:37 2016

Revert of [css-grid] Avoid the HashMap for the override containing block size (patchset #1 id:1 of https://codereview.chromium.org/2176633002/ )

Reason for revert:
Speculative Revert for Win10 Failing Tests:
fast/text/emphasis-combined-text.html
svg/W3C-SVG-1.1/filters-composite-02-b.svg

Original issue's description:
> [css-grid] Avoid the HashMap for the override containing block size
>
> The change made in r406557 caused a 12% regression on the grid layout
> performance tests. The root cause is that as part of the changes
> required to implement the orthogonal flows support we decided to use
> physical directions to determine whether a grid item overflows its
> grid area or not. Since we store the logical sizes in a HashMap, we
> implemented some utility methods that, based on the grid container's
> writing mode, retrieve the stored width or height from the HashMap.
>
> Since the previous logic was reusing the already computed logical
> value, the change introduced a considerable performance regression.
>
> This patch address the issue by removing the utility methods and
> determine the physical sizes directly inside the layout logic.
>
> BUG= 630448 
>
> Committed: https://crrev.com/2cf9f05031414616d3d1eb1e5ffa5013e396d61b
> Cr-Commit-Position: refs/heads/master@{#407762}

TBR=svillar@igalia.com,cbiesinger@chromium.org,rego@igalia.com,jfernandez@igalia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 630448 

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

[modify] https://crrev.com/04a768e5991c6e4d0967320e8b563930769439c9/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/04a768e5991c6e4d0967320e8b563930769439c9/third_party/WebKit/Source/core/layout/LayoutBox.h
[modify] https://crrev.com/04a768e5991c6e4d0967320e8b563930769439c9/third_party/WebKit/Source/core/layout/LayoutGrid.cpp
[modify] https://crrev.com/04a768e5991c6e4d0967320e8b563930769439c9/third_party/WebKit/Source/core/layout/LayoutGrid.h

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

commit e2bf9ba77a6b9add6c7a703be1fa85814c79c12e
Author: jfernandez <jfernandez@igalia.com>
Date: Wed Jul 27 18:55:31 2016

[css-grid] Avoid the HashMap for the override containing block size

The change made in r406557 caused a 12% regression on the grid layout
performance tests. The root cause is that as part of the changes
required to implement the orthogonal flows support we decided to use
physical directions to determine whether a grid item overflows its
grid area or not. Since we store the logical sizes in a HashMap, we
implemented some utility methods that, based on the grid container's
writing mode, retrieve the stored width or height from the HashMap.

Since the previous logic was reusing the already computed logical
value, the change introduced a considerable performance regression.

This patch address the issue by removing the utility methods and
determine the physical sizes directly inside the layout logic.

BUG= 630448 

Committed: https://crrev.com/2cf9f05031414616d3d1eb1e5ffa5013e396d61b
Review-Url: https://codereview.chromium.org/2176633002
Cr-Original-Commit-Position: refs/heads/master@{#407762}
Cr-Commit-Position: refs/heads/master@{#408203}

[modify] https://crrev.com/e2bf9ba77a6b9add6c7a703be1fa85814c79c12e/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/e2bf9ba77a6b9add6c7a703be1fa85814c79c12e/third_party/WebKit/Source/core/layout/LayoutBox.h
[modify] https://crrev.com/e2bf9ba77a6b9add6c7a703be1fa85814c79c12e/third_party/WebKit/Source/core/layout/LayoutGrid.cpp
[modify] https://crrev.com/e2bf9ba77a6b9add6c7a703be1fa85814c79c12e/third_party/WebKit/Source/core/layout/LayoutGrid.h