Ensure sizes test is measuring the right things on Windows |
||
Issue descriptionWe've moved the sizes step to the main perf waterfall, so that we're certain it runs on official release builds. When we get the hardware provisioned, we can run it on every revision. Now we'd like to ensure that it is measuring the right things. Here is the code: https://code.google.com/p/chromium/codesearch#chromium/build/scripts/slave/chromium/sizes.py&q=sizes.py Here are the graphs: 64 bit: https://chromeperf.appspot.com/report?sid=eba2ad635949ffec14154c4fdca41c549d71a14aa0334f55cfe508597167e28f 32 bit: https://chromeperf.appspot.com/report?sid=d9781b15d48cc8e83fbffab2f988f8aa21a9c1e89d941fcdc542412c7b9f50b1 Does this all look correct? If so, what should we monitor? It's currently set to monitor just chrome.dll. Assigning to Greg to answer the questions. Thanks for your help!!
,
Jul 13 2016
Monitoring updated.
,
Sep 15 2016
Hi sullivan: It looks like chrome.exe had a regression on Aug 11, growing by 150% (from 991,232 bytes to 2,513,408 bytes) on official builds. This is visible on the dashboard, but was a bug filed for it? If not, is there a way we can get bugs filed automagically for regressions like this? Thanks!
,
Sep 15 2016
Ah, looks like there was a miscommunication: we were monitoring chrome.dll as per summary and setup.exe and mini_installer.exe per comment 1, looks like we should also add chrome.exe. I have fixed the monitoring so this will trigger alerts in the future.
,
Sep 16 2016
Awesome! Thanks. |
||
►
Sign in to add a comment |
||
Comment 1 by grt@chromium.org
, Jul 13 2016Status: Assigned (was: Untriaged)