Binary Size Reduction Task Force

985 views
Skip to first unread message

Anthony LaForge

unread,
Mar 9, 2011, 4:55:54 PM3/9/11
to chromium-dev
Howdy Folks,

We are going to launch a new task force next week to start aggressively looking at options to bring down the size of Chrome distribution binaries.  If you are interested in spending time on this focus area please let me know and I'll be sure to include you in the kick off meeting.

Size growth of Chrome over the past couple years:

1.0 - 154.65 - May 7, 2009 - 9.0 MB
2.0 - 172.43 - Aug 26, 2009 - 9.18 MB 
3.0 - 195.38 - Oct 16, 2009 - 11.2 MB
4.0 - 249.89 - Feb 10, 2010 - 12.5 MB
5.0 - 375.127 - May 24, 2010 - 17.3 MB
6.0 - 472.63 - Sep 23, 2010 - 20.3 MB
7.0 - 517.44 - Nov 4, 2010 - 22.5 MB 
8.0 - 552.237 - Jan 12, 2011 - 24.2 MB
9.0 - 597.98 - Feb 11, 2011 - 25.7 MB 
10.0 - 648.127 - Mar 03, 2011 - 26.2 MB

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

Lei Zhang

unread,
Mar 9, 2011, 5:06:23 PM3/9/11
to laforge...@google.com, Anthony LaForge, chromium-dev
Are we concentrating on Windows or is this for all platforms?

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

Evan Martin

unread,
Mar 9, 2011, 5:27:38 PM3/9/11
to the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev

Anthony LaForge

unread,
Mar 9, 2011, 5:28:23 PM3/9/11
to Lei Zhang, laforge...@google.com, chromium-dev
Windows is the primary target for size reduction, but my guess would be that whatever set of solutions we arrive at will have implications to all platforms.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA


On Wed, Mar 9, 2011 at 2:06 PM, Lei Zhang <the...@chromium.org> wrote:

Robert Sesek

unread,
Mar 9, 2011, 7:11:09 PM3/9/11
to ev...@chromium.org, the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev, Sailesh Agrawal

Sailesh Agrawal

unread,
Mar 9, 2011, 7:22:10 PM3/9/11
to Robert Sesek, ev...@chromium.org, the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
pngcrush only reduces it by 1152 bytes though

Sailesh Agrawal

unread,
Mar 9, 2011, 7:35:01 PM3/9/11
to Robert Sesek, ev...@chromium.org, the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
Hm... I think the 1.5 MB must be another change.

The new icons actually reduce the src/chrome/app/theme/chromium directory size by 129KB!

On Wed, Mar 9, 2011 at 4:11 PM, Robert Sesek <rse...@chromium.org> wrote:

Evan Stade

unread,
Mar 9, 2011, 8:44:39 PM3/9/11
to sa...@chromium.org, Robert Sesek, ev...@chromium.org, the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev, John Abd-El-Malek
yea, the whole app/themes/chromium directory is <500k in total, so it
seems unlikely to be that. Webkit roll doesn't look responsible. Maybe
the graph is slightly deceptive (delayed) and it's actually r77249?

-- Evan Stade

John Abd-El-Malek

unread,
Mar 9, 2011, 9:03:23 PM3/9/11
to Evan Stade, sa...@chromium.org, Robert Sesek, ev...@chromium.org, the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
On Wed, Mar 9, 2011 at 5:44 PM, Evan Stade <est...@chromium.org> wrote:
yea, the whole app/themes/chromium directory is <500k in total, so it
seems unlikely to be that. Webkit roll doesn't look responsible. Maybe
the graph is slightly deceptive (delayed) and it's actually r77249?

That moved a few files from chrome to content.  I doubt it increased the size, let alone 1.5MB?

Yuzo Fujishima

unread,
Mar 9, 2011, 9:26:08 PM3/9/11
to laforge...@google.com, Anthony LaForge, chromium-dev
Hi, Anthony,

Please allow me to ask a naive question: Why do we want to reduce the size of Chrome distribution binaries?

Yuzo

--

Ian Fette

unread,
Mar 9, 2011, 9:29:41 PM3/9/11
to yu...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
Many reasons, but two off the top of my head: 1. We do distribution deals with Chrome, where we bundle Chrome with other products. These get difficult when our binary grows. 2. We see increased download failures / install dropoffs as the binary grows, especially in countries with poor bandwidth like India. India also happens to be a very good market for Chrome (we have good market share there and growing), so that's also very problematic.

-Ian

Peter Kasting

unread,
Mar 9, 2011, 9:53:09 PM3/9/11
to i...@chromium.org, yu...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
On Wed, Mar 9, 2011 at 6:29 PM, Ian Fette <i...@chromium.org> wrote:
2. We see increased download failures / install dropoffs as the binary grows, especially in countries with poor bandwidth like India.

Corrolary: It's just nicer to users to make them wait less time to install.

PK

Lei Zhang

unread,
Mar 9, 2011, 9:58:04 PM3/9/11
to yu...@chromium.org, chromium-dev
Remember not everyone has good broadband. For instance, many people in
the US have 'basic broadband' plans of 700Kbps down. At this rate,
26.2 MB takes 5 minutes to download.

On Wed, Mar 9, 2011 at 6:26 PM, Yuzo Fujishima <yu...@chromium.org> wrote:

Paweł Hajdan, Jr.

unread,
Mar 10, 2011, 2:53:17 AM3/10/11
to laforge...@google.com, Anthony LaForge, chromium-dev
On Wed, Mar 9, 2011 at 22:55, Anthony LaForge <laf...@chromium.org> wrote:
Size growth of Chrome over the past couple years:

1.0 - 154.65 - May 7, 2009 - 9.0 MB
2.0 - 172.43 - Aug 26, 2009 - 9.18 MB 
3.0 - 195.38 - Oct 16, 2009 - 11.2 MB
4.0 - 249.89 - Feb 10, 2010 - 12.5 MB
5.0 - 375.127 - May 24, 2010 - 17.3 MB
6.0 - 472.63 - Sep 23, 2010 - 20.3 MB
7.0 - 517.44 - Nov 4, 2010 - 22.5 MB 
8.0 - 552.237 - Jan 12, 2011 - 24.2 MB
9.0 - 597.98 - Feb 11, 2011 - 25.7 MB 
10.0 - 648.127 - Mar 03, 2011 - 26.2 MB

I wonder if it can be related to increased usage of bundled libraries (of course that'd not be the only reason). According to Evan Martin's http://neugierig.org/software/chromium/bloat/ third_party (excluding WebKit) takes a few MB. I'm not sure how recent is that graph, but it may be worth it to consider a stricter policy on adding new pieces of code to third_party.

By the way, I think the efforts to de-inline code also help to save some binary size.

Also, I think that the distributed package contains several things other than chrome executable. It would be interesting to see how much space is taken by the resources (translations, themes, inspector, bundled extensions if any).

Yuzo Fujishima

unread,
Mar 10, 2011, 3:14:14 AM3/10/11
to Lei Zhang, chromium-dev
Thank you for the explanations. Now I see it.

Yuzo

Adam Barth

unread,
Mar 10, 2011, 3:16:18 AM3/10/11
to phajd...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev

At a more macro level, adding MB to Chrome is pretty invisible to
developers. It's a tragedy of the commons, where each of us grazes
our cows just a bit and piles on just a few more KB. Performance
would be the same, except we're fanatical about not regress startup or
page load performance. Maybe we need to be more fanatical about not
regressing binary size?

Adam

Marc-Andre Decoste

unread,
Mar 10, 2011, 9:04:37 AM3/10/11
to aba...@chromium.org, phajd...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev

Good point, if it's not police'd, it won't happen... Do we have a plan somewhere for memory metrics and monitoring, similar to how we do it for performance?

BYE
MAD

> Le 10 mars 2011 03:17, "Adam Barth" <aba...@chromium.org> a écrit :

Chase Phillips

unread,
Mar 10, 2011, 4:36:42 PM3/10/11
to m...@chromium.org, aba...@chromium.org, phajd...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
I will add the sizes steps into the expectations system so these steps turn red if unexpected regressions occur.  It will be less useful for small regressions, but for large unexpected increases, catching them sooner should help a lot.

Anthony LaForge

unread,
Mar 11, 2011, 5:00:12 PM3/11/11
to Chase Phillips, m...@chromium.org, aba...@chromium.org, phajd...@chromium.org, laforge...@google.com, chromium-dev
Chase,

Thank you for setting up the monitoring.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA


Raymes Khoury

unread,
Mar 11, 2011, 7:10:43 PM3/11/11
to Chromium-dev, bjanak...@google.com
Hi,

There may be some things the can be done on the compiler side. I did a
quick experiment with the icf (identical code folding) optimization in
the gold linker. There is a 2mb reduction in the size of linux Chrome.

Without ICF / With ICF
size: 68210896 / 66219112
text: 49524344 / 51483120

This one doesn't hurt performance, so it should probably be turned on
as long as all tests pass. I did LDFLAGS.target="-Wl,--icf=safe"

There are other things that can be experimented with but they are
likely to have performance tradeoffs. For example, tuning inlining can
reduce binary size, sometimes even with a performance improvement.

Raymes

On Mar 11, 2:00 pm, Anthony LaForge <lafo...@chromium.org> wrote:
> Chase,
>
> Thank you for setting up the monitoring.
>
> Kind Regards,
>
> Anthony Laforge
> Technical Program Manager
> Mountain View, CA
>
>
>
>
>
>
>
> On Thu, Mar 10, 2011 at 1:36 PM, Chase Phillips <c...@chromium.org> wrote:
> > I will add the sizes steps into the expectations system so these steps turn
> > red if unexpected regressions occur.  It will be less useful for small
> > regressions, but for large unexpected increases, catching them sooner should
> > help a lot.
>
> > On Thu, Mar 10, 2011 at 06:04, Marc-Andre Decoste <m...@chromium.org>wrote:
>
> >> Good point, if it's not police'd, it won't happen... Do we have a plan
> >> somewhere for memory metrics and monitoring, similar to how we do it for
> >> performance?
>
> >> BYE
> >> MAD
>
> >> > Le 10 mars 2011 03:17, "Adam Barth" <aba...@chromium.org> a écrit :
>
> >> --
> >> Chromium Developers mailing list: chromium-...@chromium.org

Raymes Khoury

unread,
Mar 11, 2011, 7:17:54 PM3/11/11
to Chromium-dev, bjanak...@google.com
Sorry I got the text numbers backward:

Without ICF / With ICF
size: 68210896 / 66219112
text: 51483120 / 49524344

Frank Barchard

unread,
Mar 16, 2011, 2:12:34 PM3/16/11
to the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
On Tue, Mar 15, 2011 at 4:49 PM, Lei Zhang <the...@chromium.org> wrote:
FYI, on 64-bit Linux, I did a release build for Chrome with -O2 vs -Os.

Binary size (O2 vs Os, in MB)
64 / 55

I don't know what the performance impact is.

I benchmarked these options in Google Talk
O2 is 15% faster, but 20% larger.
So in Talk we use Os for most code, and O2 for the performance critical code... library by library.

Evan Martin

unread,
Mar 16, 2011, 2:14:32 PM3/16/11
to fbar...@chromium.org, the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev

I converted this thread into a bug:
http://code.google.com/p/chromium/issues/detail?id=76288

We should put your info on there too. By Talk, do you mean the plugin?

Frank Barchard

unread,
Mar 16, 2011, 3:28:30 PM3/16/11
to Evan Martin, the...@chromium.org, laforge...@google.com, Anthony LaForge, chromium-dev
Yes.  Google Talk Plugin.
I did similar tests on ffmpeg for <video>, but my data is older.
It was originally O3.  Going to O2 saved about 25% size, and performance actually improved on Pentium4, but went down on Atom, and about the same on Core.  Os reduced the size a tad more, but hurt performance too much.

On video, there are 2 things to consider
1. libvpx is larger than need be.  Its filed in the vp8 bug tracking as bug #1 :-)
It used to be way larger than necessary, because the decoder was accidently pulling in portions of the encoder.
Now we use chromoting, we're stuck with the encoder, but its still alot larger than necessary.
By alot, I mean about ~300KB.
2. ffmpeg is larger than necessary.  I suggested 'dead stripping'
The size can be reduced if/when we remove H264/AAC and/or other formats.
current sizes:
1,817,614 avcodec-52.dll
188,942 avformat-52.dll
96,782 avutil-50.dll
H264 removed:
1,369,614 avcodec-52.dll
167,950 avformat-52.dll
98,830 avutil-50.dll

Lei Zhang

unread,
Mar 15, 2011, 7:49:19 PM3/15/11
to laforge...@google.com, Anthony LaForge, chromium-dev
FYI, on 64-bit Linux, I did a release build for Chrome with -O2 vs -Os.

Binary size (O2 vs Os, in MB)
64 / 55

Stripped:
52 / 41

lzma -9 compressed:
16 / 13

I don't know what the performance impact is.

> --
> Chromium Developers mailing list: chromi...@chromium.org

Anthony LaForge

unread,
Mar 21, 2011, 4:14:07 PM3/21/11
to Frank Barchard, Evan Martin, the...@chromium.org, laforge...@google.com, chromium-dev
Howdy folks,

I went and created a new mailing alias to help channel discussions related to the distribution binary size reduction efforts.  Any chromium.org member who wants to should be able to do so.


Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

crizCraig

unread,
Mar 22, 2011, 6:19:17 PM3/22/11
to Chromium-dev
outsider here:

Wondering if some things could be lazy loaded like the native client
or gpu modules here:
http://neugierig.org/software/chromium/bloat/

That would remove ~400k. Lazy loader code would obviously offset this
some.

Developer tools, extensions, and themes might be other good candidates
for lazy loading.

Probably not the lowest hanging fruit, but could provide a good
general framework for maintaining low code size as more features are
added.
> > Chromium Developers mailing list: chromium-...@chromium.org

Sigurður Ásgeirsson

unread,
Mar 23, 2011, 4:27:36 PM3/23/11
to laforge...@google.com, Anthony LaForge, chromium-dev
Syzygy [http://go/syzygy-design] is already instrumenting and profiling all of Chrome.dll. We've set ourselves an OKR to create a tool in Q2 to make it easy to identify dynamically dead code from those profiles [http://cotools.corp.google.com/easyokrs/objectives.php?u=syzygy-team].

With the binary rewriting machinery we have, it's also fairly easy to excise such code and to e.g. redirect all callers to an error reporting function (though proving correctness for the resultant binary might be difficult :).

On Wed, Mar 9, 2011 at 4:55 PM, Anthony LaForge <laf...@chromium.org> wrote:
Howdy Folks,

We are going to launch a new task force next week to start aggressively looking at options to bring down the size of Chrome distribution binaries.  If you are interested in spending time on this focus area please let me know and I'll be sure to include you in the kick off meeting.

Size growth of Chrome over the past couple years:

1.0 - 154.65 - May 7, 2009 - 9.0 MB
2.0 - 172.43 - Aug 26, 2009 - 9.18 MB 
3.0 - 195.38 - Oct 16, 2009 - 11.2 MB
4.0 - 249.89 - Feb 10, 2010 - 12.5 MB
5.0 - 375.127 - May 24, 2010 - 17.3 MB
6.0 - 472.63 - Sep 23, 2010 - 20.3 MB
7.0 - 517.44 - Nov 4, 2010 - 22.5 MB 
8.0 - 552.237 - Jan 12, 2011 - 24.2 MB
9.0 - 597.98 - Feb 11, 2011 - 25.7 MB 
10.0 - 648.127 - Mar 03, 2011 - 26.2 MB

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

--
Chromium Developers mailing list: chromi...@chromium.org

Anthony LaForge

unread,
Mar 23, 2011, 7:52:58 PM3/23/11
to Sigurður Ásgeirsson, laforge...@google.com, chromium-dev
The syzygy project looks quite cool, have you tried to run it on WPO code?

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA


Anthony LaForge

unread,
Mar 23, 2011, 7:54:48 PM3/23/11
to Sigurður Ásgeirsson, laforge...@google.com, chromium-dev
Noticed something interesting today.  Looks like there is a 3M delta between the unsigned mini_installer.exe and the signed full installer for 12.0.712.0 (23M versus 26.2M).

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA


Sigurður Ásgeirsson

unread,
Mar 24, 2011, 2:55:40 PM3/24/11
to Anthony LaForge, laforge...@google.com, chromium-dev
On Wed, Mar 23, 2011 at 7:52 PM, Anthony LaForge <laf...@google.com> wrote:
The syzygy project looks quite cool, have you tried to run it on WPO code?

Yes, we work on released Chrome binaries (all you need as input is the binaries and their symbols).

Arunprasad Rajkumar

unread,
Oct 18, 2012, 12:52:34 PM10/18/12
to chromi...@chromium.org, laf...@chromium.org
Whether this issue still exists?


Because of above issue 20% of code size may be increased in gcc based toolchains.

Bernhard Bauer

unread,
Oct 18, 2012, 1:03:57 PM10/18/12
to ararun...@gmail.com, Chromium-dev, laf...@chromium.org
I appreciate the concern about the Chromium binary size, but a question about GCC bugs might really better be asked on a GCC mailing list.

Bernhard.


--
Reply all
Reply to author
Forward
0 new messages