Binary Size Reduction Task Force

[Anthony LaForge]

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]

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]

The really scary one is
http://build.chromium.org/f/chromium/perf/mac-release/sizes/report.html?history=2000&header=Chromium.app&graph=Chromium.app&rev=-1

Up to 84mb!

[Anthony LaForge]

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]

The new icons bumped us up 1.5 MB [1]. Can we pngcrush these?

[1] http://build.chromium.org/f/chromium/perf/mac-release/sizes/report.html?history=100&header=Chromium.app&graph=Chromium.app&rev=-1

rsesek / @chromium.org

[Sailesh Agrawal]

http://codereview.chromium.org/6646031/

pngcrush only reduces it by 1152 bytes though

[Sailesh Agrawal]

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]

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]

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]

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]

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]

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]

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.]

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]

Thank you for the explanations. Now I see it.

Yuzo

[Adam Barth]

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]

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]

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]

Chase,

Thank you for setting up the monitoring.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

[Raymes Khoury]

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]

Sorry I got the text numbers backward:

Without ICF / With ICF
size: 68210896 / 66219112

text: 51483120 / 49524344

[Frank Barchard]

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]

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]

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 :-)

http://code.google.com/p/webm/issues/detail?id=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'

http://code.google.com/p/chromium/issues/detail?id=51246

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]

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]

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.

https://groups.google.com/a/chromium.org/group/size-reduction/

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

[crizCraig]

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]

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]

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]

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]

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]

Whether this issue still exists?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187

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

[Bernhard Bauer]

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.

--