Issue metadata
Sign in to add a comment
|
66.1% improvement in rendering.mobile/thread_total_all_cpu_time_per_frame at 604976:605021 |
||||||||||||||||||||||
Issue descriptionSuspiciously large improvement, did something break?
,
Nov 8
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/15711925e40000
,
Nov 8
📍 Found a significant difference after 1 commit. https://pinpoint-dot-chromeperf.appspot.com/job/15711925e40000 Telemetry: remove old cpu_per_frame metrics by chiniforooshan@chromium.org https://chromium.googlesource.com/chromium/src/+/af5198be3516b3e7e5f54e9cdf6dc2882e1e4100 thread_total_all_cpu_time_per_frame: 91.69 → 31.05 (-60.63) Understanding performance regressions: http://g.co/ChromePerformanceRegressions Benchmark documentation link: https://bit.ly/rendering-benchmarks
,
Nov 8
This is expected. We changed the definition of frame from renderer compositor frame to display compositor frame in this metric. So, thread_*_cpu_time_per_frame should roughly change proportional to frame_times / mean_frame_time_renderer_compositor In this case, the above ratio is 18.301 / 55.21 = 0.3314, which is pretty close to the new value / old value of the metric, i.e. 31.05 / 91.69 = 0.3386. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Nov 8