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
