The fuchsia-binary-size trybot exists for two reasons:
The bot provides analysis using:
Generate commit size analysis files step of the trybotGenerate Diffs step. This summarizes how each package grew, shrank, or stayed the same.cast_runner and web_engine.Look at the provided commit size analysis files stdout to understand where the size is coming from.
Read diff results stdout will also give a breakdown of growth by package, if any.See if any of the generic optimization advice is applicable.
If you are writing a new feature or including a new library you might want to think about skipping the web_engine/cast_runner binaries and to restrict this new feature/library to desktop platforms that might care less about binary size.
is_fuchsia BUILD tag and OS_FUCHSIA macro.web_engine/cast_runner, you should also guard against the ARCH_CPU_ARM64 tag, as this CPU-architecture is the only (current) set that requires size-checks.If reduction is not practical, add a rationale for the increase to the commit description. It should include:
Add a footer to the commit description along the lines of:
Fuchsia-Binary-Size: Size increase is unavoidable (see above).Fuchsia-Binary-Size: Increase is temporary.Fuchsia-Binary-Size: See commit description. <-- use this if longer than one line.Fuchsia-Binary-Size: and other footers.The size metric we care about the most is the compressed size. This is an estimate of how large the Chrome-Fuchsia packages will be when delivered on device (actual compression can vary between devices, so the computed numbers may not be accurate). However, you may see the uncompressed and compressed size grow by different amounts (and sometimes the compressed size is larger than the uncompressed)!
This is due to how sizes are calculated and how the compression is done. The uncompressed size is exactly that: the size of the package before it is compressed.
Compression is done via the blobfs-compression tool, exported from the Fuchsia SDK. This compresses the file into a package that is ready to be deployed to the Fuchsia device. With the current (default) compression-mode, this compresses the package in page-sizes designed for the device and filesystem. Since each page is at least 8K, increments in the compressed size are always multiples of 8K with the current compression mode. So, if your change causes the previous compression page to go over the limit, you may see an 8K increase for an otherwise small change.
Large changes will increase more than a page‘s work (to at least 16K), which is why we only monitor 12K+ changes (12K isn’t possible due to the 8K page size) and not 8K+.
If you want to check your changes impact to binary size locally (instead of against the trybot), do the following:
Add the following to your .gclient config:
{
# ... whatever you have here ...
"solutions": [
{
# ...whatever you have here...
}
],
"target_os": [
"fuchsia"
],
}
Then run gclient sync to add the fuchsia-sdk to your third_party directory.
Set up a build directory with the following GN Args:
dcheck_always_on = false is_debug = false is_official_build = true target_cpu = "arm64" target_os = "fuchsia" use_goma = true
Build the fuchsia_sizes target:
autoninja -C <path/to/out/dir> fuchsia_sizes
Run the size script with the following command:
build/fuchsia/binary_sizes.py --build-out-dir <path/to/out/dir>
The size breakdown by blob and package will be given, followed by a summary at the end, for chrome_fuchsia, web_engine, and cast_runner. The number that is deployed to the device is the compressed version.
TODO(crbug.com/1296349): Fill this out.
(shamelessly stolen from this doc, but looking for any tips on how to improve this for Fuchsia specifically)
Look at blobs and see that there aren't a huge number of blobs added in.