I spent some quality time with nm. With it I can take a release binary (so all the inlining and optimizations like dead code removal have been done) and display symbol sizes as well as which file they're from.
My Release Linux build stripped is 39.5mb. (The size bots show ~44mb, which I think is a Chrome vs Chromium thing. It is curious how the Windows binary is nearly half the size of the Linux or Mac one.) My hacky script managed to total up stats for only 23mb of the binary. I'm not sure where the rest is going but it could be the ICU data tables or even just references to external functions in shared objects. Below are the top offenders, in bytes, contributing to binary size (recall again that this is a release build), as measured by how nm attributes symbols to source files. Note that it didn't attribute a bunch of code (for reasons I don't understand) and those are summed in the plain "code" entry below. And like I had guessed, SVG at the top! I promise I didn't cook these to confirm my own hypothesis. Also note that much of the rest is template-heavy code -- I was surprised to see logging.h scores almost 100kb. 2043226 read only data 762291 third_party/WebKit/WebCore/svg/SVGAnimatedProperty.h 394334 /usr/include/c++/4.4/bits/vector.tcc 270298 /usr/include/c++/4.4/bits/stl_tree.h 262889 uninitialized data 230389 code 196369 ./base/task.h 187574 third_party/WebKit/JavaScriptCore/wtf/HashTable.h 184647 third_party/WebKit/JavaScriptCore/wtf/HashMap.h 157126 ./ipc/ipc_message_utils.h 140424 v8/src/x64/codegen-x64.cc 136807 third_party/libxml/xmlschemas.c 117240 third_party/WebKit/WebCore/css/CSSStyleSelector.cpp 113895 v8/src/runtime.cc 103056 chrome/renderer/render_view.cc 97702 ./base/logging.h 95653 third_party/glew/src/glew.c 95389 third_party/libxml/parser.c 89488 /usr/include/c++/4.4/bits/stl_algo.h 84431 third_party/WebKit/JavaScriptCore/wtf/Vector.h 83865 v8/src/objects.cc 82528 third_party/icu/source/common/uchar_props_data.c 82042 third_party/WebKit/WebCore/css/CSSParser.cpp 81699 third_party/WebKit/WebCore/dom/Document.cpp 79284 third_party/libxml/xpath.c 73821 third_party/icu/source/i18n/ucol.cpp 73796 third_party/WebKit/WebCore/rendering/RenderBlock.cpp 68578 third_party/WebKit/WebCore/loader/FrameLoader.cpp 59865 third_party/libxml/HTMLparser.c 59048 third_party/WebKit/WebCore/svg/SVGAnimatedTemplate.h 58057 third_party/libxml/relaxng.c 57535 out/Release/obj/gen/protoc_out/chrome/browser/sync/protocol/sync.pb.cc 56253 v8/src/parser.cc 56000 third_party/icu/source/i18n/decimfmt.cpp 54954 global ctors 51952 v8/src/api.cc On Fri, Nov 13, 2009 at 2:39 PM, Evan Martin <e...@chromium.org> wrote: > We track total binary size here: > http://build.chromium.org/buildbot/perf/dashboard/sizes.html > > I don't know of any place we track per-module sizes. > > On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel <esei...@chromium.org> wrote: >> Do we have any hard data about where our binary size goes? It seems >> such data would be very useful. >> >> On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin <e...@chromium.org> wrote: >>> I measured that SVG is nearly a sixth of the binary size of a Chrome >>> debug build. That's not only more compile time, it's also more link >>> time for each incremental link and more time for the debugger to grind >>> it when starting gdb. For my day-to-day debugging I would like to >>> build without SVG (and many other bits, but let's start with SVG). >>> >>> I put on one obvious patch and one patch I'm not sure about at >>> https://bugs.webkit.org/show_bug.cgi?id=31490 >>> >>> Does anyone have thoughts about the right way to disable SVG in the GYP >>> files? >>> Here's the hacky second patch mentioned above: >>> https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196 >>> In particular, I'm not sure of the right way to conditionally build >>> the SVGNames bits. >>> >>> I've seen in some cases files are completely wrapped with "#if >>> ENABLE(FOO)"; do you know when that is appropriate? >>> >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >>> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
