metrics.md

Binary Size Metrics

This document lists metrics used to track binary size.

[TOC]

Metrics for Desktop

• Sizes are collected by //build/scripts/slave/chromium/sizes.py
  • Win32 Telemetry Graphs
  • Linux Telemetry Graphs
  • Mac Telemetry Graphs

Alerting

• Alerts are sheriffed as part of the main perf sheriff rotation.
• Alerts generally fire for ~100kb jumps.

Metrics for Android

For Googlers, more information available at go/chrome-apk-size.

• Sizes are collected by //build/android/resource_sizes.py.
• How to analyze Android binary size discussed in apk_size_regressions.md#debugging-apk-size-increase.
• Sizes for ChromePublic.apk, ChromeModernPublic.apk, MonochromePublic.apk, SystemWebview.apk are tracked.
  • But only MonochromePublic.apk is actively monitored.
• We care most about on-disk size (for users with small device storage)
  • But also care about patch size (so that browser updates get applied)

Normalized APK Size

• Telemetry Graph
• Monitored by Binary Size Sheriffs.
  • Alerts fire for changes of 16kb or more.
• Computed as:
  • The size of an APK
  • With all native code as the sum of section sizes (except .bss), uncompressed.
    • Why: Removes effects of ELF section alignment.
  • With all dex code as if it were stored uncompressed.
    • Why: Best practice is to store dex uncompressed on Android P and above.
    • On prior versions, or when stored compressed, dex is extracted upon installation.
  • With all zipalign padding removed.
    • Why: Removes effects of file alignment (esp. relevant because native libraries are 4k-aligned).
  • With size of apk signature block removed.
    • Why: Size fluctuates by several KB based on how hash values turn out.
  • With all translations as if they were not missing (estimates size of missing translations based on size of english strings).
    • Why: Without translation-normalization, translation dumps cause jumps.
    • Translation-normalization applies only to apks (not to Android App Bundles).
• For Android App Bundles, the normalized size is the sum of the normalized size of all splits that have onDemand="false" (those installed by default).

Native Code Size Metrics

• Telemetry Graph
• File size of libchrome.so
• Code vs data sections (.text vs .data + .rodata)

Java Code Size Metrics

• Telemetry Graph
• File size of classes.dex
• "Dex": Counts of the number of fields, methods, strings, types.
• "DexCache": The number of bytes of RAM required to load our dex file (computed from counts)

Breakdown Metrics

• Telemetry Graph
• Compressed size of each apk component.
• The sum of these equals APK Size (which can be found under "Install Size Metrics": "APK Size")

Install Metrics

• Telemetry Graph
• Estimated installed size: How much disk is required to install Chrome on a device.
  • This is just an estimate, since actual size depends on Android version (e.g. Dex overhead is very different for pre-L vs L+).
  • Does not include disk used up by profile, etc.
  • We believe it to be fairly accurate for all L+ devices (less space is required for Dalvik runtime pre-L).
• The sum of these equals Estimated installed size.

Transfer Size Metrics

• Deflated apk size:
  • Telemetry Graph
  • Only relevant for non-patch updates of Chrome (new installs, or manual app updates)
• Patch Size (no longer available):
  • Is too slow to be running on the Perf Builder
  • Was found to be fairly unactionable
  • Used to use https://github.com/googlesamples/apk-patch-size-estimator
  • Functionality now exists in //third_party/android_sdk/public/cmdline-tools/latest/bin/apkanalyzer download-size

Uncompressed Metrics

• Telemetry Graph
• Uncompressed size of classes.dex, locale .pak files, etc
• Reported only for things that are compressed within the .apk

Metrics for LaCrOS

• Sizes are collected by //build/lacros/lacros_resource_sizes.py.