These tools currently focus on supporting Android. They somewhat work with Linux builds. As for Windows, some great tools already exist and are documented here:
There is also a dedicated mailing-list for binary size discussions:
Bugs and feature requests are tracked in crbug under:
Per-Milestone Binary Size Breakdowns:
resource_sizes.py
and SuperSize.Binary-Size:
footer to be present for commits that are larger than 16KiB (autorollers exempted)..apk
without having the build directory available.Test suite="resource_sizes ($APK)"
.Collects, archives, and analyzes Chrome's binary size. Supports Android and Linux (although Linux has issues).
.size
files are gzipped plain text files that contain:
readelf -S
.map
file.nm
output, such as ** merge strings
entries, and some unnamed symbols (which although unnamed, contain the .o
path).is_official_build=true
builds if generate_linker_map
is true. In official builds on Android generate_linker_map is true by default..o
files are mapped to .cc
files by parsing .ninja
files..h
files are never listed as sources. No information about inlined symbols is gathered.** merge strings
symbols are further broken down into individual string literal symbols. This is done by reading string literals from .o
files, and then searching for them within the ** merge strings
sections.llvm-bcanalyzer
is used to extract string literals..pss
as .size / .num_aliases
.nm elf-file
..h
files.nm
on each .o
file.llvm-bcanalyzer
is used to process .o
files, which are actually LLVM Bitcode files.{shared}/$SYMBOL_COUNT
. This collapsing is done only for symbols owned by a large number of paths..cc
to numeric id.output_dir/size-info
dir.supersize
uses these two mappings to find associated source files for the pak entries found in all of the apk's .pak
files..java
files the FQN of the public class is mapped to the file..srcjar
files the FQN of the public class is mapped to the .srcjar
file path.output_dir/size-info
dir.apkanalyzer
sdk tool is used to find the size and FQN of entries in the dex file..mapping
file is available, that is used to get back the original FQN.apkanalyzer
is used by supersize
along with the mapping file to find associated source files for the dex entries found in all of the apk's .dex
files.All files in an apk that are not broken down into sub-entries are tracked by a symbol within the .other
section.
Overhead symbols track bytes that are generally unactionable. They are recorded as size=0, padding=$size
(padding-only symbols) to de-emphasize them in diffs.
elf_file_size - sum(elf_sections)
.apk_file_size - sum(compressed_file_sizes)
.zip
metadata and zipalign padding.pak_file_size - sum(pak_entries)
compressed_size_of_paks - sum(pak_entries)
Path normalization:
out/Release/
, gen/
, obj/
foo/bar.a(baz.o)
-> foo/bar.a/baz.o
base/{shared}/3
(the “3” means three different files contain the symbol)Name normalization:
(anonymous::)
is removed from names (and stored as a symbol flag).[clone]
suffix removed (and stored as a symbol flag).vtable for FOO
-> Foo [vtable]
name
: Name without template and argument parameterstemplate_name
: Name without argument parameters.full_name
: Name with all parameters.Special cases:
Clustering:
[clone]
” (removed by normalization).SizeInfo.symbols
. To view unclustered symbols, use SizeInfo.raw_symbols
.Diffing:
Simulated compression:
.pak
files are compressed and others are kept uncompressed..pak
files.No. Some examples of why it's Chrome-specific:
.ninja
build rules are available..so
given .apk
.size-info
dir in output directory to analyze .pak
and .dex
files.Collect size information and dump it into a .size
file.
Note: Refer to diagnose_bloat.py for list of GN args to build a Release binary (or just use the tool with --single).
Googlers: If you just want a .size
for a commit on master:
GIT_REV="HEAD~200" tools/binary_size/diagnose_bloat.py --single --cloud --unstripped $GIT_REV
Example Usage:
# Android: ninja -C out/Release -j 1000 apks/ChromePublic.apk tools/binary_size/supersize archive chrome.size --apk-file out/Release/apks/ChromePublic.apk -v # Linux: ninja -C out/Release -j 1000 chrome tools/binary_size/supersize archive chrome.size --elf-file out/Release/chrome -v
Creates an .ndjson
(newline-delimited JSON) file that the SuperSize viewer is able to load.
Example Usage:
# Creates the data file ./report.ndjson, generated based on ./chrome.size tools/binary_size/supersize html_report chrome.size --report-file report.ndjson -v # Includes every symbol in the data file, although it will take longer to load. tools/binary_size/supersize html_report chrome.size --report-file report.ndjson --all-symbols # Create a data file showing a diff between two .size files. tools/binary_size/supersize html_report after.size --diff-with before.size --report-file report.ndjson
Locally view the .ndjson
file generated by html_report
, by starting a web server that links to the file.
Example Usage:
# Starts a local server to view the data in ./report.ndjson tools/binary_size/supersize start_server report.ndjson # Set a custom address and port. tools/binary_size/supersize start_server report.ndjson -a localhost -p 8080
A convenience command equivalent to: console before.size after.size --query='Print(Diff(size_info1, size_info2))'
Example Usage:
tools/binary_size/supersize diff before.size after.size --all
Starts a Python interpreter where you can run custom queries, or run pre-made queries from canned_queries.py
.
Example Usage:
# Prints size infomation and exits (does not enter interactive mode). tools/binary_size/supersize console chrome.size --query='Print(size_info)' # Enters a Python REPL (it will print more guidance). tools/binary_size/supersize console chrome.size
Example session:
>>> ShowExamples() # Get some inspiration. ... >>> sorted = size_info.symbols.WhereInSection('t').Sorted() >>> Print(sorted) # Have a look at the largest symbols. ... >>> sym = sorted.WhereNameMatches('TrellisQuantizeBlock')[0] >>> Disassemble(sym) # Time to learn assembly. ... >>> help(canned_queries) ... >>> Print(canned_queries.TemplatesByName(depth=-1)) ... >>> syms = size_info.symbols.WherePathMatches(r'skia').Sorted() >>> Print(syms, verbose=True) # Show full symbol names with parameter types. ... >>> # Dump all string literals from skia files to "strings.txt". >>> Print((t[1] for t in ReadStringLiterals(syms)), to_file='strings.txt')
Determines the cause of binary size bloat between two commits. Works for Android and Linux (although Linux symbol diffs have issues, as noted below).
.size
files from perf bots (--cloud
)resource_size.py
and supersize
.# Build and diff monochrome_public_apk HEAD^ and HEAD. tools/binary_size/diagnose_bloat.py HEAD -v # Build and diff monochrome_apk HEAD^ and HEAD. tools/binary_size/diagnose_bloat.py HEAD --enable-chrome-android-internal -v # Build and diff monochrome_public_apk HEAD^ and HEAD without is_official_build. tools/binary_size/diagnose_bloat.py HEAD --gn-args="is_official_build=false" -v # Diff BEFORE_REV and AFTER_REV using build artifacts downloaded from perf bots. tools/binary_size/diagnose_bloat.py AFTER_REV --reference-rev BEFORE_REV --cloud -v # Fetch a .size, libmonochrome.so, and MonochromePublic.apk from perf bots (Googlers only): tools/binary_size/diagnose_bloat.py AFTER_REV --cloud --unstripped --single # Build and diff all contiguous revs in range BEFORE_REV..AFTER_REV for src/v8. tools/binary_size/diagnose_bloat.py AFTER_REV --reference-rev BEFORE_REV --subrepo v8 --all -v # Display detailed usage info (there are many options). tools/binary_size/diagnose_bloat.py -h