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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgjPfdrQoM


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

linux-release

=== Auto-CCing suspected CL author vogelheim@chromium.org ===

Hi vogelheim@chromium.org, 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 : Remove Expression::bounds_, in order to conserve memory during parsing.
Author  : vogelheim
Commit description:
  
Expression::bounds_ is used only by a subset of compile passes, but the
data structure occupies space for every Expression node ever parsed. This
unneccessarily increases memory consumption. Particularly, peak memory
consumption during startup, which may cause out-of-memory errors.

This CL
- removes Expression::bounds_;
- introduces an AstTypeBounds container, which mappes Expression* to Bounds;
- modifies the code that actually requires bounds information, namely
  Crankshaft compile and AsmWasmBuilder, to instantiate such an AstTypeBounds
  container before typing and to pass it to the code that consumes this
  information; and
- modifies all accesses to Expression::bounds_ to instead access the bounds
  via the container instead.

Additionally, this rewrites test-ast-expression-visitor. The reason is that
this code attempted to test AstExpressionVisitor but did so exclusively
through its subclass ExpressionTypeCollector, meaning that the test dealt
almost exclusively with type bounds despite the class-under-test having
no knowledge or functionality related to it. Worse, the test was written
in a way to assume that type bounds were available outside & after
compilation, which is something this change changes.

BUG=v8:4947

Review-Url: https://codereview.chromium.org/1968383002
Cr-Commit-Position: refs/heads/master@{#36222}
Commit  : bb04e1243e1741cffa0559f2cf7b493bf5c9c55e
Date    : Thu May 12 22:24:30 2016


===== TESTED REVISIONS =====
Revision                       Mean     Std Dev   N  Good?
chromium@393514                221.6    1.14018   5  good
chromium@393518                221.25   0.886405  8  good
chromium@393519                221.143  1.06904   7  good
chromium@393519,v8@02b7373ab1  220.6    1.14018   5  good
chromium@393519,v8@d0b6686c14  221.4    1.34164   5  good
chromium@393519,v8@bb04e1243e  218.2    0.83666   5  bad    <--
chromium@393519,v8@2e86946f0b  218.0    1.41421   5  bad
chromium@393520                218.75   1.28174   8  bad
chromium@393522                218.6    0.894427  5  bad
chromium@393529                219.25   0.707107  8  bad

Bisect job ran on: linux_perf_bisect
Bug ID: 612475

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests jetstream
Test Metric: Score/Score
Relative Change: 0.90%
Score: 99.0

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


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

| 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!

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

vogelheim@: It seems like that CL may have slightly affected the jetstream benchmark; it might be worth looking into this to make sure that it was a net positive for performance.

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Daniel, looks like your patch caused a regression. Could you take a look?

Daniel, ping.

Friendly ping from perf sheriff

Daniel, could you please verify that the Memory-speed trade off caused by your cl was intentional and worthwhile?

The jetstream regression was certainly unintentional, but in my opinion worthwhile.

-------

At that CL, Jetstream drops in mandreel-latency & geomean, but gains in code-first-load (and bigfib_cpp). The gains in page loading, approximated by codeload, where the goal of the CL, and the benefits outweigh losses in somewhat synthetic benchmarks like mandreel-latency.

Also, later work improved scores on the loosing benchmarks beyond the losses of this CL.