Blink's binary size

58 views
Skip to first unread message

Kentaro Hara

unread,
Mar 1, 2018, 12:27:40 AM3/1/18
to platform-architecture-dev, Andrew Grieve
Hi

I've learned that this tool visualizes the breakdown of Chrome's binary on Android.

The result looks very interesting!

- Blink (i.e., "WebKit") is the largest component in Chrome's binary. However, Blink consumes only 16% of Chrome's binary. This means that even if we reduced Blink by 50%, it would reduce Chrome's binary only by 8%.

- Realistically it would not be feasible to reduce Blink by 50%. Even if we drop the whole modules/ (by making modules/ dynamically pluggable), it will reduce only 1.4 MB, which is only 3% of Chrome's binary.

- Generated code (i.e., "/blink/bindings/" and "/blink/core/") consumes 1.9 MB. This is not small but is only 4% of Chrome's binary.

Overall my takeaway is: It seems like there is no low-hanging fruit from the Blink perspective. If we want to reduce 10% from Chrome's binary by reducing Blink, we'll need to invent yet another very lightweight rendering engine :)

(Note: I'm not saying that Blink doesn't need to care about the binary size. I'm just saying that it's hard to come up with a meaningful binary reduction project in Blink.)


--
Kentaro Hara, Tokyo, Japan

Daniel Cheng

unread,
Mar 1, 2018, 12:50:57 AM3/1/18
to Kentaro Hara, platform-architecture-dev, Andrew Grieve
FWIW, the last time I looked at this, the most likely gains looked to be from tweaking things in the generated bindings. Functions generated for bindings generally aren't very large, but there's a lot of them, so even saving a few bytes can end up reducing binary size.

Daniel


--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jyCZ_nbKOyJiznyQu4%2BHHem8q5swifeO3Zmk1e2usayVA%40mail.gmail.com.

Andrew Grieve

unread,
Mar 1, 2018, 9:10:00 AM3/1/18
to Daniel Cheng, Kentaro Hara, platform-architecture-dev, Andrew Grieve, binary-size
Thanks for the signal boost :)

Instructions for generating such reports are here:

One thing not covered by the visualization are module dependencies. E.g. how many //components and //third_party directories are there because of blink? (not rhetorical, I actually don't know).

I've also found that generated code is a promising spot to look for savings. You can generate code faster than writing it :). Refactoring generated code to generate less, or to generate functions that can be identical-code-folded can result in noticeable savings. Of Blink's ~9mb, 2mb is from generated code.





On Thu, Mar 1, 2018 at 12:50 AM, Daniel Cheng <dch...@chromium.org> wrote:
FWIW, the last time I looked at this, the most likely gains looked to be from tweaking things in the generated bindings. Functions generated for bindings generally aren't very large, but there's a lot of them, so even saving a few bytes can end up reducing binary size.

Daniel


On Thu, Mar 1, 2018 at 12:27 AM Kentaro Hara <har...@chromium.org> wrote:
Hi

I've learned that this tool visualizes the breakdown of Chrome's binary on Android.

The result looks very interesting!

- Blink (i.e., "WebKit") is the largest component in Chrome's binary. However, Blink consumes only 16% of Chrome's binary. This means that even if we reduced Blink by 50%, it would reduce Chrome's binary only by 8%.

- Realistically it would not be feasible to reduce Blink by 50%. Even if we drop the whole modules/ (by making modules/ dynamically pluggable), it will reduce only 1.4 MB, which is only 3% of Chrome's binary.

- Generated code (i.e., "/blink/bindings/" and "/blink/core/") consumes 1.9 MB. This is not small but is only 4% of Chrome's binary.

Overall my takeaway is: It seems like there is no low-hanging fruit from the Blink perspective. If we want to reduce 10% from Chrome's binary by reducing Blink, we'll need to invent yet another very lightweight rendering engine :)

(Note: I'm not saying that Blink doesn't need to care about the binary size. I'm just saying that it's hard to come up with a meaningful binary reduction project in Blink.)


--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

Kentaro Hara

unread,
Mar 1, 2018, 9:46:46 AM3/1/18
to Andrew Grieve, Daniel Cheng, platform-architecture-dev, binary-size
I've also found that generated code is a promising spot to look for savings. You can generate code faster than writing it :). Refactoring generated code to generate less, or to generate functions that can be identical-code-folded can result in noticeable savings. Of Blink's ~9mb, 2mb is from generated code.
https://agrieve.github.io/chrome/supersize-chrome-android-jan-04-2018/console.txt

Totally agreed! We should definitely look into this one.

Sorry for missing the context from the original email... I'm never intending to say that Blink doesn't need care about the binary size. We're now running a task force to speed up the startup time of Android Go and I wanted to answer a question: "Would it be realistic to reduce Chrome's binary by e.g., 15% by investing on Blink?".



On Thu, Mar 1, 2018 at 6:09 AM, Andrew Grieve <agr...@chromium.org> wrote:
Thanks for the signal boost :)

Instructions for generating such reports are here:

One thing not covered by the visualization are module dependencies. E.g. how many //components and //third_party directories are there because of blink? (not rhetorical, I actually don't know).

I've also found that generated code is a promising spot to look for savings. You can generate code faster than writing it :). Refactoring generated code to generate less, or to generate functions that can be identical-code-folded can result in noticeable savings. Of Blink's ~9mb, 2mb is from generated code.
On Thu, Mar 1, 2018 at 12:50 AM, Daniel Cheng <dch...@chromium.org> wrote:
FWIW, the last time I looked at this, the most likely gains looked to be from tweaking things in the generated bindings. Functions generated for bindings generally aren't very large, but there's a lot of them, so even saving a few bytes can end up reducing binary size.

Daniel


On Thu, Mar 1, 2018 at 12:27 AM Kentaro Hara <har...@chromium.org> wrote:
Hi

I've learned that this tool visualizes the breakdown of Chrome's binary on Android.

The result looks very interesting!

- Blink (i.e., "WebKit") is the largest component in Chrome's binary. However, Blink consumes only 16% of Chrome's binary. This means that even if we reduced Blink by 50%, it would reduce Chrome's binary only by 8%.

- Realistically it would not be feasible to reduce Blink by 50%. Even if we drop the whole modules/ (by making modules/ dynamically pluggable), it will reduce only 1.4 MB, which is only 3% of Chrome's binary.

- Generated code (i.e., "/blink/bindings/" and "/blink/core/") consumes 1.9 MB. This is not small but is only 4% of Chrome's binary.

Overall my takeaway is: It seems like there is no low-hanging fruit from the Blink perspective. If we want to reduce 10% from Chrome's binary by reducing Blink, we'll need to invent yet another very lightweight rendering engine :)

(Note: I'm not saying that Blink doesn't need to care about the binary size. I'm just saying that it's hard to come up with a meaningful binary reduction project in Blink.)


--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

Richard Townsend

unread,
Mar 1, 2018, 1:17:10 PM3/1/18
to Kentaro Hara, Andrew Grieve, Daniel Cheng, platform-architecture-dev, binary-size
One thing I’ve noticed from browsing the codebase is that a lot of large-ish functions are force-inlined, it my be interesting to determine if the benefit is worth the increase in binary size (since larger binaries generally generate more instruction cache pressure too).

From: har...@google.com <har...@google.com> on behalf of Kentaro Hara <har...@chromium.org>
Sent: Thursday, March 1, 2018 8:46:14 AM
To: Andrew Grieve
Cc: Daniel Cheng; platform-architecture-dev; binary-size
Subject: Re: Blink's binary size
 
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jxkY-H1UJcfWQ0da_uuOtwGjmrDdFPU7y2t3p7PKJD%3DDw%40mail.gmail.com.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Kentaro Hara

unread,
Mar 1, 2018, 1:21:22 PM3/1/18
to Richard Townsend, Andrew Grieve, Daniel Cheng, platform-architecture-dev, binary-size
Interesting.

Andrew: Do you have any insights on how much we can reduce the code size if we use e.g., -Os for Blink?



To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Andrew Grieve

unread,
Mar 1, 2018, 1:25:41 PM3/1/18
to Kentaro Hara, Richard Townsend, Andrew Grieve, Daniel Cheng, platform-architecture-dev, binary-size
At one point, I would have said ~3MB. However, with the introduction of AFDO, we realized about 1.6MB of this. So it'd be on the order of about 1.5MB that -Os would save us now, and it would certainly hurt perf.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

PhistucK

unread,
Mar 1, 2018, 1:41:05 PM3/1/18
to Andrew Grieve, Kentaro Hara, Richard Townsend, Daniel Cheng, platform-architecture-dev, binary-size
What is AFDO?


☆PhistucK

You received this message because you are subscribed to the Google Groups "binary-size" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-size+unsubscribe@chromium.org.
To post to this group, send email to binar...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/CABiQX1XoeURhQDFYuF_OA7w6S283VZAieA1pE7snp9Qsb3-zZg%40mail.gmail.com.

Jeremy Roman

unread,
Mar 1, 2018, 1:43:54 PM3/1/18
to PhistucK, Andrew Grieve, Kentaro Hara, Richard Townsend, Daniel Cheng, platform-architecture-dev, binary-size
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

Andrew Grieve

unread,
Mar 1, 2018, 1:58:23 PM3/1/18
to Jeremy Roman, PhistucK, Andrew Grieve, Kentaro Hara, Richard Townsend, Daniel Cheng, platform-architecture-dev, binary-size
Ah sorry, restricted bug :/. The TLDR of it is that there are now profiles used by the compiler to know how aggressively to compile each function. They live here: //chrome/android/profiles (downloaded via runhook).


Reply all
Reply to author
Forward
0 new messages