Issue metadata
Sign in to add a comment
|
10.9% regression in system_health.common_desktop at 457899:457967 |
||||||||||||||||||||||
Issue descriptionStory: search_portal_google Metric: mousewheel_animation:power_avg
,
Mar 22 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8984403200367327472
,
Mar 22 2017
,
Mar 22 2017
=== BISECT JOB RESULTS === Bisect was unable to run to completion Error: INFRA_FAILURE The bisect was able to narrow the range, you can try running with: good_revision: d1aaa76016c981807fbe10c53c00de6061200c98 bad_revision : 652e402f4703bf20297438b059d75c6884ba0d1f If failures persist contact the team (see below) and report the error. Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457898 12.537 +- 0.289581 6 good chromium@457916 12.5927 +- 0.322774 6 good chromium@457925 12.4923 +- 0.189396 6 good chromium@457929 13.7389 +- 1.06142 6 bad chromium@457933 14.1974 +- 3.34503 6 bad chromium@457967 13.6533 +- 0.618768 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8984403200367327472 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5638640996188160 | 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 Speed>Bisection. Thank you!
,
Mar 22 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8984389475959897328
,
Mar 22 2017
(Running with narrowed range...)
,
Mar 22 2017
=== Auto-CCing suspected CL author wangxianzhu@chromium.org === Hi wangxianzhu@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 : wangxianzhu Commit : 5b49d1384ce8d1a8594bdb49f9f392da784b43bf Date : Sat Mar 18 02:20:11 2017 Subject: Reland of Add 'WithoutGeometryChange' variants of paint invalidation flag setters (patchset #1 id:1 of https://codereview.chromium.org/2752093005/ ) Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Change : 9.23% | 12.4587777467 -> 13.6083156432 Revision Result N chromium@457925 12.4588 +- 0.299324 6 good chromium@457927 12.5716 +- 0.307572 6 good chromium@457928 13.7732 +- 0.59123 6 bad <-- chromium@457929 13.6083 +- 0.479599 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8984389475959897328 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=6721794167275520 | 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 Speed>Bisection. Thank you!
,
Mar 23 2017
Hi Xianzhu, It looks like your reland CL has caused a ~10% regression in power required to scroll many pages. Is this expected? Here's a link to the trace before your CL was landed: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_50-2017-03-17_21-15-18-95303.html Here's a link to a trace after your CL was landed: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_50-2017-03-18_10-54-27-84188.html
,
Mar 23 2017
,
Mar 24 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8984275543569461008
,
Mar 24 2017
Thanks charliea@ for the links to the traces. I'm not sure if I interpret the traces correctly: - with patch, the durations of scroll response are shorter than those without patch. - with patch, input latencies are shorter If the interpretations are correct, do they mean that with the patch performance is better? I guess with faster response to input events, we may animate more frames during the mouse wheel animation, resulting more power usage.
,
Mar 24 2017
Another difference between the traces is the durations of 'paint' which are longer with patch. Will investigate.
,
Mar 24 2017
=== BISECT JOB RESULTS === Perf regression found with culprit Suspected Commit Author : wangxianzhu Commit : 5b49d1384ce8d1a8594bdb49f9f392da784b43bf Date : Sat Mar 18 02:20:11 2017 Subject: Reland of Add 'WithoutGeometryChange' variants of paint invalidation flag setters (patchset #1 id:1 of https://codereview.chromium.org/2752093005/ ) Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Change : 8.55% | 12.6084437146 -> 13.6867936066 Revision Result N chromium@457898 12.6084 +- 0.464118 6 good chromium@457916 12.6301 +- 0.570335 6 good chromium@457925 12.607 +- 0.43911 9 good chromium@457927 12.4832 +- 0.426687 6 good chromium@457928 13.7192 +- 0.608469 6 bad <-- chromium@457929 13.4756 +- 1.56778 9 bad chromium@457933 13.7547 +- 0.379316 6 bad chromium@457967 13.6868 +- 0.599468 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8984275543569461008 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=6459217315102720 | 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 Speed>Bisection. Thank you!
,
Mar 24 2017
A couple things worth noting: looking at the Chrome IO thread, each "burst" in the before trace takes about 3.5ms. In the after trace, each "burst" takes 6.5ms. On CrRendererMain, in the before trace, MessageLoop::RunTask during the scroll seems to take about 4.2ms at longest. In the after trace, MessageLoop::RunTask seems to regularly take 6.5ms. Unless these were expected outcomes of the change you made, I strongly encourage you to revert the CL and do some profiling offline to better understand the performance implications of the change.
,
Mar 24 2017
The regression is related by the new call to setMayNeedPaintInvalidation() from setNeedsOverflowRecalcAfterStyleChange(). The latter is set on the containing block of an object which changed transform style during the scroll. After that, during paint invalidation we find that some objects changed location so invalidated their display item clients and their painting layer. During painting, we repainted the invalidated painting layers. The repaints actually used all cached display items because the invalidated display items happen to produce no painted result. The CL seems to have fixed a tricky under-invalidation issue, but I'm yet to create a reduced test case to reproduce the issue, and investigate any optimizations to reduce the cost. Before that, will remove the call first to fix the regression.
,
Mar 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d3fc0f37f5b506fbc57edfdeebe02cbeac5b3002 commit d3fc0f37f5b506fbc57edfdeebe02cbeac5b3002 Author: wangxianzhu <wangxianzhu@chromium.org> Date: Fri Mar 24 21:21:46 2017 Remove setMayNeedPaintInvalidation call from setNeedsOverflowRecalcAfterStyleChange() This is a partial revert of https://codereview.chromium.org/2751523011 which caused extra painting cost in some cases. See the bug for data and analysis. Remove the call to fix the regression. Will continue to investigate the case to see if the extra painting cost is legitimate and, if yes, any optimizations to avoid the cost. BUG= 704182 Review-Url: https://codereview.chromium.org/2776583003 Cr-Commit-Position: refs/heads/master@{#459556} [modify] https://crrev.com/d3fc0f37f5b506fbc57edfdeebe02cbeac5b3002/third_party/WebKit/Source/core/layout/LayoutObject.cpp
,
Mar 27 2017
wangxianzhu@: it looks like the patch you submitted on Friday didn't have the hoped-for effect with regards to reducing power usage. The graph for ToT is still higher than ref: https://chromeperf.appspot.com/group_report?bug_id=704182. At this point, it'd be best if you reverted your changes and debugged the regression locally. Leaving it landed risks the regression remaining in place long-term.
,
Mar 27 2017
Revert is here: https://codereview.chromium.org/2779683002/. It depends on another revert https://codereview.chromium.org/2772353002/ for bug 704728 . This is a trace after the #17 CL: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_49-2017-03-27_00-48-34-18441.html. It shows that the paint time is already reduced to nearly zero during the scroll. There seems no other reasons causing the power usage increase except for the improved latency of scroll events (which seems to increase FPS during scroll). I'm verifying this and trying to find the reason (which might have happened just after my original CL which caused the paint time regression).
,
Mar 27 2017
Now I have the following hypothesis: - My CL r457928 caused regression of paint time, resulting more cpu usage in each frame update; - Some later CL in r457929:r457967 improved performance of input event handling, resulting higher FPS and fewer idle frames. The CL in #17 fixed the regression of paint time, but because we still have fewer idle frame updates (which should be a good thing), the power usage didn't drop much. Proofs: 1. Trace at r457933 (just after my CL): https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-03-22_10-43-10-20660.html 2. Trace at r457967 (the latest change in the regression range): https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_50-2017-03-18_10-54-27-84188.html 3. Trace at r459694 (after #17 CL): https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_49-2017-03-27_00-48-34-18441.html Paint time Idle frames Scroll event latency 1 High More High 2. High Less Low 3. Low Less Low Based on the above traces, I think the status of ToT is good. charliea@ I would like to collect more traces between r457933 and r457967, but failed: https://codereview.chromium.org/2775363002/. The bot refuses to collect traces for benchmarks that always collect traces. I'm trying to use "Bisect" for the purpose but I wonder if there is better way for it.
,
Mar 27 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983946477418381328
,
Mar 27 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983946451192966016
,
Mar 27 2017
At 1), there are 155 paint events during a 1.471s scroll animation (paint_1.png_ At 2), there are 89 Paint events during the 1.452s scroll animation (paint_2.png) At 3), there are 86 paint events during the 1.44s scroll animation (paint_3.png) This definitely substantiates your claim that there are fewer idle frames after your CL in #c17.
,
Mar 27 2017
I think the following data may better reflect the changes:
Total paint time Paint events MouseWheel latency
0) 2.2ms 74 37.2ms
1) 61.9ms 158 34.7ms
2) 78.4ms 176 18.9ms
3) 3.0ms 90 6.7ms
It should not be #c17 CL but some CL in r457929:r457967 that caused fewer idle frames. I would like to find it using bisect tool.
,
Mar 27 2017
By my measurements, your CL change the average power while successfully painting frames from around 25W to around 27.5W. See: before.png and after.png, where I grabbed a bunch of power samples during successful paints. I'm definitely seeing that your CL reduces the number of missed frames - or, at least, it reduces the frequency at which obvious "spikes" are missing in the power graph, which I assume connotes a missed frame. See: before_spikes.png and after_spikes.png.
,
Mar 27 2017
Which revisions are "before_spikes.png" and "after_spikes.png"?
,
Mar 27 2017
r457898 and r457967, respectively (the last CL before and the first CL after the regression introduced by your CL in this graph: https://chromeperf.appspot.com/report?sid=3f0db261863b145cd7142c0058cb35abbcc7485bfb8ecdb4198c97d2e2d79d32)
,
Mar 27 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457955 16.0112 +- 1.97569 21 good chromium@457967 16.0913 +- 1.37687 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983946451192966016 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5004906827612160 | 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 Speed>Bisection. Thank you!
,
Mar 27 2017
There are two effects in the difference between r457898 and r457967: 1. Increased CPU usage in each frame which I believe has been fixed by #c17 CL; 2. More spikes which I think is caused by some CL in r457929:r457967. the trace of r457933 (trace 1 in #c20) shows the first effect but not the second effect. The most obvious difference between r457933 and r457967 (trace 2 in #c20) is the latency of scroll events. The small blue bars at the top of the graph are longer and overlap more in r457933 than in r457967.
,
Mar 27 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983940458876391792
,
Mar 27 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983940298554965712
,
Mar 27 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983940272326097856
,
Mar 27 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457945 13.7543 +- 2.67563 21 good chromium@457967 13.6306 +- 0.917558 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983946477418381328 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5024445841801216 | 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 Speed>Bisection. Thank you!
,
Mar 27 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983939574573072864
,
Mar 27 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457940 13.533 +- 1.25469 21 good chromium@457948 13.5879 +- 1.56393 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983940458876391792 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5410959612444672 | 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 Speed>Bisection. Thank you!
,
Mar 27 2017
=== BISECT JOB RESULTS === Bisect failed for unknown reasons Please contact the team (see below) and report the error. Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983940298554965712 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5817340693839872 | 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 Speed>Bisection. Thank you!
,
Mar 27 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457942 13.5914 +- 1.57853 21 good chromium@457946 13.6574 +- 1.21096 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983940382011381664 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=6722197961310208 | 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 Speed>Bisection. Thank you!
,
Mar 27 2017
=== BISECT JOB RESULTS === Bisect failed for unknown reasons Please contact the team (see below) and report the error. Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983940411750125392 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5826066188337152 | 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 Speed>Bisection. Thank you!
,
Mar 27 2017
I gave up bisecting to the revision which caused less idle frame updates (i.e. low scroll/mousewheel latency, better scroll performance, smoother scroll, and higher CPU usage during scrolling), because the same revision produced different results. For example, r457940 produces both high scroll latency (https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-03-27_13-24-56-7140.html) and low scroll latency (https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-03-27_13-23-50-82414.html). As we always produce low scroll latency, and the paint time regression has been fixed, I'm closing this bug and won't land the revert.
,
Mar 27 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457935 13.7053 +- 1.19664 21 good chromium@457938 13.8728 +- 3.89852 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983939574573072864 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5901731432497152 | 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 Speed>Bisection. Thank you!
,
Mar 27 2017
=== BISECT JOB RESULTS === Bisect failed for unknown reasons Please contact the team (see below) and report the error. Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983940272326097856 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=6184900236935168 | 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 Speed>Bisection. Thank you!
,
Mar 28 2017
Reopening until benhenry@ makes a decision on this: /cc benhenry@: Ben is the TPM of speed releasing and is the ultimate arbiter of performance tradeoffs within Chrome. wangxianzhu@ believes that his change which caused a 10.9% power regression in scrolling (at least on some sites) is okay, as this extra energy goes towards successful paints in order to achieve 60fps. I can see that there's increased power use, but don't have the trace analysis skills required to figure out whether the claim that there's a better frame rate is true. Could you help me to validate this and, if it's true, verify that this is a performance tradeoff we're comfortable making (it seems like it very likely is, but you're the final decider on these choices)
,
Mar 28 2017
,
Mar 28 2017
I pinged tdresser@ offline (he's in an ML class now, so couldn't give much of a response), but he confirmed by looking at the traces that the scroll FPS is much better after the first CL that was landed. I can confirm that the extra invalidations go away after the partial revert, although those fewer invalidations didn't lead to the power savings we were hoping for. All of this corroborates wangxianzhu's belief that this is very likely a power performance regression that's worthwhile due to higher scroll FPS.
,
Mar 28 2017
Based on the traces, this does appear to improve things significantly. Average Gesture Scroll Update latency went from 34ms to 19ms, which is huge. I'd feel more confident with a trace that included the FrameViewer output though, to verify that the frames being produced are different. Does this change effect many pages, or does this only change behavior on a small subset of sites?
,
Mar 28 2017
Does this affect only mac? +shrike to help make the call on tradeoffs. I really don't have the context or data to help weigh 200% improvement on rendering vs. 10.9% regression on power specifically during scroll or if the offending CL could be done in more power-efficient ways with the same affect.
,
Mar 28 2017
> Does this affect only mac? That would be interesting to know. The scroll test is Mac only (at least I don't see it for Windows) so there's no data on how this change affects Windows. The power regression is not 10% across the board - it's 18% on cnn, 36% on instagram. Those are all large increases, but it's hard to argue that this change should be reverted (i.e. that we should keep power use down by keeping rendering in a broken state).
,
Mar 29 2017
That's a fair point. So this isn't really about tradeoffs. Re-closing. Charlie - thanks for bringing this up.
,
Mar 29 2017
The instagram regression has recovered after r459556. Note that the reason of reduction of scroll latency happened between r457933 and r457967 is still not clear. r457928 caused regression of paint time during scroll, which has been fixed by r459556. I believe r457928 is not the reason of reduction of scroll latency, because trace of r457933 (trace 1 in #c20) still show long scroll latency. I tried to find out which revision improved scroll performance but failed because lacking of proper tool. The regression of ChromiumPerf/chromium-rel-mac-retina/system_health.common_desktop / scroll_response:energy_sum / browse_news / seems not belonging to this bug, because the regression range is r458827 - r459118 for browse_news_flipboard and browse_news_reddit. I think we should file another bug for this regression.
,
Mar 29 2017
I moved regression of ChromiumPerf/chromium-rel-mac-retina/system_health.common_desktop / scroll_response:energy_sum / browse_news / browse_news_cnn to bug 705977 .
,
Mar 29 2017
Ah, sorry about that. Thanks everyone for bringing this to a resolution, especially to wangxianzhu@ who was very responsive about investigating his regression.
,
Apr 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/347d17a607d7f379ba66bb4904869c1b530aac2b commit 347d17a607d7f379ba66bb4904869c1b530aac2b Author: wangxianzhu <wangxianzhu@chromium.org> Date: Tue Apr 04 20:53:55 2017 setMayNeedPaintInvalidation in setNeedsOverflowRecalcAfterStyleChange() This is to ensure needsPaintOffsetAndVisualRectUpdate() when overflow will change because of style change. It was added in https://codereview.chromium.org/2751523011/ then removed in https://codereview.chromium.org/2776583003/ because it caused paint time regression when scrolling google search result page. This CL adds it back, and added a condition to avoid unnecessary paint invalidation when a container's location changes. BUG= 704182 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Review-Url: https://codereview.chromium.org/2791933003 Cr-Commit-Position: refs/heads/master@{#461829} [modify] https://crrev.com/347d17a607d7f379ba66bb4904869c1b530aac2b/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/347d17a607d7f379ba66bb4904869c1b530aac2b/third_party/WebKit/Source/core/paint/PaintInvalidationTest.cpp [modify] https://crrev.com/347d17a607d7f379ba66bb4904869c1b530aac2b/third_party/WebKit/Source/core/paint/PaintInvalidator.cpp
,
Apr 10 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982663553679256608
,
Apr 10 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982659711118697536
,
Apr 10 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457955 13.7786 +- 1.92376 21 good chromium@457967 13.8537 +- 1.60734 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8982663553679256608 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5004906827612160 | 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 Speed>Bisection. Thank you!
,
Apr 11 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982615963953399584
,
Apr 11 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: mac_retina_perf_bisect Benchmark : system_health.common_desktop Metric : mousewheel_animation:power_avg/search_portal/search_portal_google Revision Result N chromium@457945 13.4927 +- 2.10346 21 good chromium@457967 13.5576 +- 1.10006 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=search.portal.google system_health.common_desktop Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8982659711118697536 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5024445841801216 | 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 Speed>Bisection. Thank you!
,
Apr 11 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982611734198638976
,
May 4 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by charliea@chromium.org
, Mar 22 2017