Issue metadata
Sign in to add a comment
|
+5% memory regression in native heap webview svelte |
||||||||||||||||||||||
Issue descriptionPerf dashboard: https://chromeperf.appspot.com/report?sid=f3a1dd8ca7a733171d9c56ad6f6da1c908b0aabf3c4f3991484e66cc1f8abe3a&start_rev=403457&end_rev=403659 Health dashboard: https://chrome-health.googleplex.com/health-plan/android-webview/memory/nexus4-svelte/?from_commit=403382&to_commit=403665 Range: http://test-results.appspot.com/revision_range?start=403648&end=403650 (tiny: 3 CLs) Sneaked in right before the change of the benchmark to TBMv2
,
Jul 6 2016
perezju@, so, https://chromium.googlesource.com/chromium/src/+/c7537ac3e1d33fff191a is the TBMv2 switch? Could you explain a little what are the changes? Note that I have another candidate complex text on Android activation after the benchmarks were switched to default teardown: https://codereview.chromium.org/2123653005
,
Jul 6 2016
Yes, the TBMv2 switch was migrating the way in which we extract metric values out of traces. It did not have any measurable effects (as expected!) on the values reported by benchmarks (except for graphics reported by chrome, c.f. issue 625976). Thanks for the heads up on the reland of your CL. I'll also try to keep an eye on how that affects our measurements. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by perezju@chromium.org
, Jul 6 2016Status: Duplicate (was: Untriaged)