All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=789637

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


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

Android Builder

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8961563961754443088

It looks like this increase was probably unexpected or might be avoidable.
Please have a look and either:

Close as “Won't Fix” with a short justification, or
Land a revert / fix-up.

mlippautz - can you take a look? 72 Kb is a fairly sizable regression on Android.

Deleted: diff_results.txt 2.0 MB

diff_results.txt 2.0 MB View Download

=== BISECT JOB RESULTS ===
NO Perf regression found, tests failed to produce values

Bisect Details
  Configuration: android_nexus7_perf_bisect
  Benchmark    : resource_sizes
  Metric       : MonochromePublic.apk_Specifics/normalized apk size


To Run This Test
  src/build/android/resource_sizes.py --chromium-output-directory {CHROMIUM_OUTPUT_DIR} --chartjson {CHROMIUM_OUTPUT_DIR}/apks/MonochromePublic.apk

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

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


For feedback, file a bug with component Speed>Bisection

The regression is sort of intended. The barrier is core infrastructure for garbage collection improvements. 

We might be able to optimize the size by outlining a few things though. Let me keep this open and assigned to me.

The optimization in faf0c6646d65d165018b9af7331033b4c358e7ba is getting back 40960.

I realize that it is still ~30k but considering that this is core garbage collection infrastructure I think the increase is justified. 

Agreed. Thanks for your efforts!