You're off by a digit -- read only data is 2mb. On Mon, Nov 16, 2009 at 3:27 PM, Eric Seidel <esei...@chromium.org> wrote: > 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