2009/11/16 Evan Martin <[email protected]> > 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 >
This is tangential to the core of your question, but just to check, are asserts disabled on linux release builds? There are numerous calls to ASSERT within the templated functions in SVGAnimateedProperty so it seems they could easily blow up the binary size if the template is instantiated many times. Linux is the one platform I have yet to setup builds for otherwise I'd look myself (OSX appears to use the same ASSERT definition so might have similar symptoms) > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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: [email protected] > >>> View archives, change email options, or unsubscribe: > >>> http://groups.google.com/group/chromium-dev > >>> > >> > > > > -- > Chromium Developers mailing list: [email protected] > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
