In case it's not clear, the box sizes are proportional to their fraction of the containing box.
Caveats: - The total of the displayed symbols is less than the actual Chrome binary size. This is due to nm not knowing about all the components of our binary, or the sizes of every symbol; for example, we put the ICU data table in our binaries but that is not included here. - nm also sometimes doesn't know which source file a given symbol comes from; those all are placed in the "symbols without paths" bucket. - Note that a given component of Chrome might have its code across multiple directories; for example, WebCore code exists in the big WebCore box but also in the generated bindings found in out/Release/obj/gen/webcore/bindings as well as in the misc "vtable for WebCore::" box (which contains all vtables namespaced to WebCore::). Or how sync includes chrome/browser/sync but is also responsible for the multiple jingle boxes.
> In case it's not clear, the box sizes are proportional to their > fraction of the containing box.
> Caveats: > - The total of the displayed symbols is less than the actual Chrome > binary size. This is due to nm not knowing about all the components > of our binary, or the sizes of every symbol; for example, we put the > ICU data table in our binaries but that is not included here. > - nm also sometimes doesn't know which source file a given symbol > comes from; those all are placed in the "symbols without paths" > bucket. > - Note that a given component of Chrome might have its code across > multiple directories; for example, WebCore code exists in the big > WebCore box but also in the generated bindings found in > out/Release/obj/gen/webcore/bindings as well as in the misc "vtable > for WebCore::" box (which contains all vtables namespaced to > WebCore::). Or how sync includes chrome/browser/sync but is also > responsible for the multiple jingle boxes.
>> In case it's not clear, the box sizes are proportional to their >> fraction of the containing box.
>> Caveats: >> - The total of the displayed symbols is less than the actual Chrome >> binary size. This is due to nm not knowing about all the components >> of our binary, or the sizes of every symbol; for example, we put the >> ICU data table in our binaries but that is not included here. >> - nm also sometimes doesn't know which source file a given symbol >> comes from; those all are placed in the "symbols without paths" >> bucket. >> - Note that a given component of Chrome might have its code across >> multiple directories; for example, WebCore code exists in the big >> WebCore box but also in the generated bindings found in >> out/Release/obj/gen/webcore/bindings as well as in the misc "vtable >> for WebCore::" box (which contains all vtables namespaced to >> WebCore::). Or how sync includes chrome/browser/sync but is also >> responsible for the multiple jingle boxes.
> >> In case it's not clear, the box sizes are proportional to their > >> fraction of the containing box.
> >> Caveats: > >> - The total of the displayed symbols is less than the actual Chrome > >> binary size. This is due to nm not knowing about all the components > >> of our binary, or the sizes of every symbol; for example, we put the > >> ICU data table in our binaries but that is not included here. > >> - nm also sometimes doesn't know which source file a given symbol > >> comes from; those all are placed in the "symbols without paths" > >> bucket. > >> - Note that a given component of Chrome might have its code across > >> multiple directories; for example, WebCore code exists in the big > >> WebCore box but also in the generated bindings found in > >> out/Release/obj/gen/webcore/bindings as well as in the misc "vtable > >> for WebCore::" box (which contains all vtables namespaced to > >> WebCore::). Or how sync includes chrome/browser/sync but is also > >> responsible for the multiple jingle boxes.
