Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 ================================================================================ | |
| 2 __________ .__ | |
| 3 \______ \ |__| ____ _____ _______ ___.__. | |
| 4 | | _/ | | / \ \__ \ \_ __ \ < | | | |
| 5 | | \ | | | | \ / __ \_ | | \/ \___ | | |
| 6 |______ / |__| |___| / (____ / |__| / ____| | |
| 7 \/ \/ \/ \/ | |
| 8 _________ .__ ___________ .__ | |
| 9 / _____/ |__| ________ ____ \__ ___/ ____ ____ | | | |
| 10 \_____ \ | | \___ / _/ __ \ | | / _ \ / _ \ | | | |
| 11 / \ | | / / \ ___/ | | ( <_> ) ( <_> ) | |__ | |
| 12 /_______ / |__| /_____ \ \___ > |____| \____/ \____/ |____/ | |
| 13 \/ \/ \/ | |
| 14 ================================================================================ | |
| 15 | |
| 16 -------------------------------------------------------------------------------- | |
| 17 Introduction | |
| 18 -------------------------------------------------------------------------------- | |
| 19 The ever-increasing size of binaries is a problem for everybody. Increased | |
| 20 binary size means longer download times and a bigger on-disk footprint after | |
| 21 installation. Mobile devices suffer the worst, as they frequently have | |
| 22 sub-optimal connectivity and limited storage capacity. Developers currently | |
| 23 have almost no visibility into how the space in the existing binaries is | |
| 24 divided nor how their contributions change the space within those binaries. | |
| 25 The first step to reducing the size of binaries is to make the size information | |
| 26 accessible to everyone so that developers can take action. | |
| 27 | |
| 28 The Binary Size Tool does the following: | |
| 29 1. Runs "nm" on a specified binary to dump the symbol table | |
| 30 2. Runs a parallel pool of "addr2line" processes to map the symbols from the | |
| 31 symbol table back to source code (way faster than running "nm -l") | |
| 32 3. Creates (and optionally saves) an intermediate file that accurately mimcs | |
| 33 (binary compatible with) the "nm" output format, with all the source code | |
| 34 mappings present | |
| 35 4. Parses, sorts and analyzes the results | |
| 36 5. Generates an HTML-based report in the specified output directory | |
| 37 | |
| 38 | |
| 39 -------------------------------------------------------------------------------- | |
| 40 How to Run | |
| 41 -------------------------------------------------------------------------------- | |
| 42 Running the tool is fairly simply. For the sake of this example we will | |
| 43 pretend that you are building the Content Shell APK for Android. | |
| 44 | |
| 45 1. Build your product as you normally would, e.g.: | |
| 46 ninja -C out/Release -j 100 content_shell_apk | |
| 47 | |
| 48 2. Build the "binary_size_tool" target from ../../build/all_android.gyp, e.g.: | |
| 49 ninja -C out/Release binary_size_tool | |
| 50 | |
| 51 3. Run the tool specifying the library and the output report directory. | |
| 52 This command will run the analysis on the Content Shell native library for | |
| 53 Android using the nm/addr2line binaries from the Android NDK for ARM, | |
| 54 producing an HTMl report in /tmp/report: | |
|
Andrew Hayden (chromium.org)
2014/01/16 16:11:38
The 'L' in HTML should not be lowercase.
| |
| 55 tools/binary_size/run_binary_size_analysis.py \ | |
| 56 --library out/Release/lib/libcontent_shell_content_view.so \ | |
| 57 --destdir /tmp/report \ | |
| 58 --arch android-arm | |
| 59 | |
| 60 Of course, there are additional options that you can see by running the tool | |
| 61 with "--help". | |
| 62 | |
| 63 This whole process takes about an hour on a modern (circa 2014) quad-core | |
| 64 machine. If you have LOTS of RAM, you can use the "--jobs" argument to | |
| 65 add more addr2line workers; doing so will *greatly* reduce the processing time | |
| 66 but will devour system memory. If you've got the horsepower, 10 workers can | |
| 67 thrash through the binary in about 5 minutes at a cost of around 60 GB of RAM. | |
| 68 | |
| 69 -------------------------------------------------------------------------------- | |
| 70 Analyzing the Output | |
| 71 -------------------------------------------------------------------------------- | |
| 72 When the tool finishes its work you'll find an HTML report in the output | |
| 73 directory that you specified with "--destdir". Open the index.html file in your | |
| 74 *cough* browser of choice *cough* and have a look around. The index.html page | |
| 75 is likely to evolve over time, but will always be your starting point for | |
| 76 investigation. From here you'll find links to various views of the data such | |
| 77 as treemap visualizations, overall statistics and "top n" lists of various | |
| 78 kinds. | |
| 79 | |
| 80 The report is completely standalone. No external resources are required, so the | |
| 81 report may be saved and viewed offline with no problems. | |
| 82 | |
| 83 -------------------------------------------------------------------------------- | |
| 84 Caveats | |
| 85 -------------------------------------------------------------------------------- | |
| 86 The tool is not perfect and has several shortcomings: | |
| 87 | |
| 88 * Not all space in the binary is accounted for. The cause is still under | |
| 89 investigation. | |
| 90 * The tool is partly written in Java, temporarily tying it to Android | |
| 91 purely and solely because it needs Java build logic which is only defined | |
| 92 in the Android part of the build system. The Java portions need to be | |
| 93 rewritten in Python so we can decouple from Android, or we need to find | |
| 94 an alternative (readelf, linker maps, etc) to running nm/addr2line. | |
| 95 * The Java code assumes that the library file is within a Chromium release | |
| 96 directory. This limits it to Chromium-based binaries only. | |
| 97 * The Java code has a hack to accurately identify the source of ICU data | |
| 98 within the Chromium source tree due to missing symbols in the ICU ASM | |
|
Andrew Hayden (chromium.org)
2014/01/16 16:11:38
It's not missing symbols, it's that we don't provi
| |
| 99 output. | |
| 100 * The Python script assumes that arm-based and mips-based nm/addr2line | |
| 101 binaries exist in ../../third_party. This is true only when dealing with | |
|
Andrew Hayden (chromium.org)
2014/01/16 16:11:38
... in the android_ndk directory.
| |
| 102 Android and again limits the tool to Chromium-based binaries. | |
| 103 * The Python script uses build system variables to construct the classpath | |
| 104 for running the Java code. | |
| 105 * The Javascript code in the HTML report Assumes code lives in Chromium for | |
| 106 generated hyperlinks and will not hyperlink any file that starts with the | |
| 107 substring "out". | |
| 108 | |
| 109 -------------------------------------------------------------------------------- | |
| 110 Feature Requests and Bug Reports | |
| 111 -------------------------------------------------------------------------------- | |
| 112 Please file bugs and feature requests here, making sure to use the label | |
| 113 "Binary-Size-Tool": | |
| 114 https://code.google.com/p/chromium/issues/entry?labels=Binary-Size-Tool | |
| 115 | |
| 116 View all open issues here: | |
| 117 https://code.google.com/p/chromium/issues/list?can=2&q=label:Binary-Size-Tool | |
| OLD | NEW |