New issue
Advanced search Search tips

Issue 774072 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

2.3%-2.4% regression in memory.top_10_mobile at 507682:507779

Project Member Reported by primiano@chromium.org, Oct 12 2017

Issue description

See the link to graphs below.
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Oct 12 2017

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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=7879ed5dc0e70fdf3b82347041a3bf15f006b0ba15f526358189cd3b9a066c5b


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

android-nexus5X
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Oct 12 2017

Cc: chiniforooshan@chromium.org
Owner: chiniforooshan@chromium.org
Status: Assigned (was: Untriaged)

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

Hi chiniforooshan@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Ehsan Chiniforooshan
  Commit : c77b44ebb53886e039c8471548c2050cceceda59
  Date   : Tue Oct 10 18:12:10 2017
  Subject: tracing: TracingController -> Coordinator

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:chrome:all_processes:reported_by_chrome:malloc:effective_size_avg/background/after_https_m_facebook_com_rihanna
  Change       : 1.85% | 42067636.0 -> 42846862.6667

Revision             Result                   N
chromium@507681      42067636 +- 357100       6      good
chromium@507706      41583044 +- 797148       9      good
chromium@507712      41524524 +- 720523       9      good
chromium@507715      41488319 +- 753894       6      good
chromium@507716      41392617 +- 736281       6      good
chromium@507717      42267185 +- 615396       6      bad       <--
chromium@507718      42183378 +- 1182039      9      bad
chromium@507730      42745745 +- 883593       6      bad
chromium@507779      42846863 +- 493481       6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=https.m.facebook.com.rihanna memory.top_10_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8965933552536737440


For feedback, file a bug with component Speed>Bisection
Project Member

Comment 4 by 42576172...@developer.gserviceaccount.com, Oct 12 2017

 Issue 774086  has been merged into this issue.
Project Member

Comment 5 by 42576172...@developer.gserviceaccount.com, Oct 14 2017

Issue 774075 has been merged into this issue.
Project Member

Comment 6 by 42576172...@developer.gserviceaccount.com, Oct 14 2017

Issue 774078 has been merged into this issue.
Status: Started (was: Assigned)
Project Member

Comment 8 by 42576172...@developer.gserviceaccount.com, Oct 17 2017

Cc: tebbi@chromium.org
 Issue 775464  has been merged into this issue.
Cc: perezju@chromium.org
Components: Speed>Tracing
There are 3 groups of regressions here: Android memory, Mac v8 duration, and desktop time to first contentful/meaningful paint.

perezju@: for the Android memory regression, do you know what does it mean that there is a clear 960K regression on memory.top_10_mobile but system_health.memory_mobile does not show a clear regression (a ~340K regression which looks like a usual noise in the metric)?

Link to the two graphs:

https://chromeperf.appspot.com/report?sid=f2d518ca55082239addd2f5db18589001f7bb0019c2862c8c80e662bc27048aa
They are running different stories, different workflows, so they tend to hit different code paths at different times. It's pretty common for regressions to show on some stories and not others, even more so to show in one benchmark but not the other.

For Memory, I would suggest to focus on the largest regression (about 1MiB in malloc), which seems to be coming from the browser process:
https://chromeperf.appspot.com/report?sid=900b11efcac44e24bac7016e953fe3663cc0beeae91702475d211791cb8a4ac4&rev=507779
chiniforooshan: Are you still working on this or do you want to close or re-assign it?
Owner: ----
Status: Available (was: Started)
No, not working on this right now; got caught up with other work. I don't think this should be closed; the cause of the regressions should be understood. I'll mark it as available for now and will come back to it when I have a little bit more time.
Cc: sullivan@chromium.org
Labels: -Performance-Sheriff
Removing the Performance-Sheriff label so this bug doesn't get weekly pings from sheriffs, since it's triaged into a component and not an urgent performance regression.

Sign in to add a comment