Yay data! Thank you Evan. If I'm reading your email correctly, your script can only account for 3MB (7.5%) of our binary. :( 26.5MB (67%) is unknown to your script and 20MB of what nm does see is labeled "read only data". Of the 3MB nm does understand, 700K (1.7% of the total final binary) is SVGAnimatedProperty.h.
Seems like we need to know where the other 92.5% of our binary is going before we take action against specific files. -eric On Mon, Nov 16, 2009 at 12:33 AM, Evan Martin <e...@chromium.org> wrote: > 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
