New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 771769 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jan 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

65.6% regression in thread_times.key_silk_cases at 506142:506222

Project Member Reported by m...@chromium.org, Oct 4 2017

Issue description

See the link to graphs below.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=771769

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


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

android-webview-nexus6

=== BISECT JOB RESULTS ===
Bisect failed for unknown reasons

Please contact the team (see below) and report the error.


Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : thread_times.key_silk_cases
  Metric       : thread_raster_cpu_time_per_frame/font_wipe.html


To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=font.wipe.html thread_times.key_silk_cases

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

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


For feedback, file a bug with component Speed>Bisection
Cc: brianosman@google.com
Owner: brianosman@google.com
Status: Assigned (was: Untriaged)

=== Auto-CCing suspected CL author brianosman@google.com ===

Hi brianosman@google.com, 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 : Brian Osman
  Commit : 7943ecb42a7841ebff9b51eb85ac7f4937537243
  Date   : Tue Oct 03 20:43:12 2017
  Subject: Disable SW path renderer mask caching in Skia

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : thread_times.key_silk_cases
  Metric       : thread_IO_cpu_time_per_frame/http___jsfiddle.net_xLuvC_1_show_
  Change       : 34.25% | 4.31205944171 -> 5.78875217372

Revision             Result                   N
chromium@506046      4.31206 +- 0.236927      6      good
chromium@506136      4.43388 +- 0.354024      6      good
chromium@506159      4.38122 +- 0.257319      6      good
chromium@506162      4.32161 +- 0.438909      6      good
chromium@506163      5.84679 +- 0.495085      6      bad       <--
chromium@506164      5.99759 +- 0.38253       6      bad
chromium@506165      5.93174 +- 0.265456      6      bad
chromium@506170      5.8958 +- 0.49218        6      bad
chromium@506181      5.95412 +- 0.368189      6      bad
chromium@506225      5.78875 +- 0.820991      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...jsfiddle.net.xLuvC.1.show. thread_times.key_silk_cases

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

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


For feedback, file a bug with component Speed>Bisection
Cc: bsalomon@chromium.org
This was a revert to previous behavior. I recently landed https://chromium.googlesource.com/skia/+/36dcd7f25d1ffee8571a7d424eb02f60cd474fa7, which added caching of mask textures when we fall back to software path rendering. That caused the speedups seen in the graphs from this bug.

It also introduced some slowdowns (on the same tests!?): https://bugs.chromium.org/p/chromium/issues/detail?id=770374

Based on that first bug, I reverted the behavior in Chrome, which led to this bug. I'm planning to investigate why things ever got slower in the first place, but we have to pick one or the other. My gut feeling is that we should enable the caching (which would fix this bug, and re-introduce the other one).
brianosman: did you make a decision here?
Sorry, no. Although looking at the two different perf regressions, this is cpu time on the IO thread (?), while the other one is actual fps. Given that, I'm inclined to leave things as-is.
Status: WontFix (was: Assigned)
Sounds good. Marking WontFix.

Sign in to add a comment