Fwd: An Update on Binary Size

[Andrew Grieve]

A New Mailing-List:

binar...@chromium.org for anything related to binary size

A New Tool (Android only for now):
//tools/binary_size/README.md

Read the README for complete details, but here's a taste:

# Builds HEAD and HEAD^, and then saves a diff of binary size.
tools/binary_size/diagnose_bloat.py HEAD
# Enter a console for inspecting native symbols archived by previous step
tools/binary_size/supersize console binary-size-bloat/*/*.size 

From the console, you can:

• Disassemble() individual symbols (uses "objdump -S" with the address of specific symbols)
• Filter & group symbols by name or path.
• Run pre-created queries (and contribute your own) via "canned_queries".
• Do all of these things on the full set of symbols, or on a symbol diff.

 

A Plea:

Code size is a shared concern, and the majority of our size comes from gradual creep. I'd like to encourage everyone to take some time to run this tool on their own patches in order to get a feel for what causes code to grow. If you aren't willing to create an android checkout, you can still try the tool out on one of your changes after submitting it using the --cloud flag.

If you watched the Google IO keynote, you'll have seen Chrome's icon on the Android Go announcement slide. 

We've got some ideas filed in crbug under Performance-Size already, but if you have ideas, I'd love if you could create bugs for them or share them with binar...@chromium.org.

Stats on Growth:

Chrome.apk grows ~1MB per release, and libchrome.so is the majority of it (~80%).

 

chromeperf graph of MonochromePublic's native code size from Apr 22 -> May 12 (20 days). 350kb of creep.

Perf Alerts:

We've got alerts set to go off for any change that increases size by more than 16kb. There are also updated instructions for dealing with these alerts at apk_size_regressions.md. If you are sheriffing, or get a resource_sizes bug assigned to you, please read this doc!

Andrew

[Michael Giuffrida]

Cool! When is this expected to work well for non-Android builds?

On Thu, May 18, 2017 at 9:02 AM 'Andrew Grieve' via Chromium-dev <chromi...@chromium.org> wrote:

A New Mailing-List:

binar...@chromium.org for anything related to binary size

A New Tool (Android only for now):
//tools/binary_size/README.md

Read the README for complete details, but here's a taste:

# Builds HEAD and HEAD^, and then saves a diff of binary size.
tools/binary_size/diagnose_bloat.py HEAD
# Enter a console for inspecting native symbols archived by previous step
tools/binary_size/supersize console binary-size-bloat/*/*.size 

From the console, you can:

• Disassemble() individual symbols (uses "objdump -S" with the address of specific symbols)
• Filter & group symbols by name or path.
• Run pre-created queries (and contribute your own) via "canned_queries".
• Do all of these things on the full set of symbols, or on a symbol diff.

 

A Plea:

Code size is a shared concern, and the majority of our size comes from gradual creep. I'd like to encourage everyone to take some time to run this tool on their own patches in order to get a feel for what causes code to grow. If you aren't willing to create an android checkout, you can still try the tool out on one of your changes after submitting it using the --cloud flag.

If you watched the Google IO keynote, you'll have seen Chrome's icon on the Android Go announcement slide. 

We've got some ideas filed in crbug under Performance-Size already, but if you have ideas, I'd love if you could create bugs for them or share them with binar...@chromium.org.

Stats on Growth:

Chrome.apk grows ~1MB per release, and libchrome.so is the majority of it (~80%).

 

chromeperf graph of MonochromePublic's native code size from Apr 22 -> May 12 (20 days). 350kb of creep.

Perf Alerts:

We've got alerts set to go off for any change that increases size by more than 16kb. There are also updated instructions for dealing with these alerts at apk_size_regressions.md. If you are sheriffing, or get a resource_sizes bug assigned to you, please read this doc!

Andrew

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABiQX1VnvRx_664Eck-sp8UCYJ8%2B_YeektGkmexb8ro_Fb3vXQ%40mail.gmail.com.

[Eric Stevenson]

Support for Linux probably won't be on par with Android in terms of functionality/usefulness for the next couple of quarters since we'll be busy with other work to decrease binary size on Android. We'll send out updates when the tool is fully ready for Linux usage :).

There are no plans to support other platforms at this time. Work on the tool can be found in the Tools>BinarySize component.

Thanks!,

Eric

[Thiago Farina]

On Thu, May 18, 2017 at 1:01 PM, 'Andrew Grieve' via blink-dev <blin...@chromium.org> wrote:

A New Mailing-List:

binar...@chromium.org for anything related to binary size

A New Tool (Android only for now):
//tools/binary_size/README.md

Read the README for complete details, but here's a taste:

# Builds HEAD and HEAD^, and then saves a diff of binary size.
tools/binary_size/diagnose_bloat.py HEAD
# Enter a console for inspecting native symbols archived by previous step
tools/binary_size/supersize console binary-size-bloat/*/*.size 

From the console, you can:

• Disassemble() individual symbols (uses "objdump -S" with the address of specific symbols)
• Filter & group symbols by name or path.
• Run pre-created queries (and contribute your own) via "canned_queries".
• Do all of these things on the full set of symbols, or on a symbol diff.

 

For Linux, https://github.com/google/bloaty might be interesting. 

--

Thiago Farina