1922272 - Investigate if the libxul binary size can be reduced

Status: NEW

(Core :: General, task)

Description

[Florian Quèze [:florian]]

Attachment: bloaty.compileunits.txt

I'm attaching the result of:
bloaty obj-aarch64-apple-darwin23.3.0/dist/bin/XUL -d compileunits --debug-file=./XUL.dSYM/Contents/Resources/DWARF/XUL -n 0 > bloaty.compileunits.txt
on my local mozilla-central build.

(bloaty was simply installed using brew install bloaty)

Here's the top of the file:

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  23.5%  56.5Mi  23.4%  56.5Mi    [__LINKEDIT]
   6.2%  14.9Mi   6.2%  14.9Mi    /Users/florian/buildhg/mozilla/intl/icu/source/i18n/smpdtfmt.cpp
   2.5%  5.96Mi   2.5%  5.96Mi    /Users/florian/buildhg/mozilla/js/src/ctypes/libffi/src/types.c
   1.5%  3.53Mi   1.5%  3.73Mi    Unified_cpp_dom_base9.cpp
   1.0%  2.43Mi   1.0%  2.43Mi    src/gl.cc
   0.9%  2.28Mi   0.9%  2.28Mi    rlbox.wasm.c
   0.8%  2.04Mi   0.8%  2.04Mi    /Users/florian/buildhg/mozilla/media/libwebp/src/utils/bit_writer_utils.c
   0.8%  1.94Mi   0.8%  1.94Mi    UnifiedBindings26.cpp

Comment 1

[Florian Quèze [:florian]]

Attachment: bloaty.symbols.txt.gz

And I'm also attaching the output of bloaty obj-aarch64-apple-darwin23.3.0/dist/bin/XUL -d symbols --debug-file=./XUL.dSYM/Contents/Resources/DWARF/XUL -n 0 > bloaty.symbols.txt
The file weights 31MB, which is above the 10MB upload limit of bugzilla, so I had to gzip it.

Here is the beginning of the file:

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  42.5%   102Mi  42.4%   102Mi    [__LINKEDIT]
   6.2%  14.8Mi   6.1%  14.8Mi    _icudt73_dat
   0.9%  2.25Mi   0.9%  2.25Mi    crossbeam_epoch::guard::unprotected::UNPROTECTED::h0dc8a4d8fb5af10c
   0.5%  1.13Mi   0.5%  1.13Mi    mozilla::(anonymous namespace)::WebGLImageConverter::run<>()
   0.4%  1.02Mi   0.4%  1.02Mi    _str.0
   0.4%  1.01Mi   0.4%  1.01Mi    kDafsa
   0.4%   930Ki   0.4%   930Ki    SKSL_MINIFIED_sksl_compute
   0.3%   838Ki   0.3%   838Ki    Base64::Encode::Base64
   0.3%   832Ki   0.3%   832Ki    webrender::shader_source::OPTIMIZED_SHADERS::h6e1801f517082430
   0.3%   817Ki   0.3%   817Ki    [__TEXT,__unwind_info]
   0.3%   649Ki   0.3%   649Ki    tabs::schema::REMOTE_CLIENTS_KEY::h31913a6e4a008033
   0.3%   642Ki   0.3%   642Ki    IPC::ParamTraits<>::Read()
   0.2%   609Ki   0.2%   609Ki    mozilla::dom::MathMLElement::MapGlobalMathMLAttributesInto()::values

Comment 2

[Florian Quèze [:florian]]

The ./XUL.dSYM folder was obtained with these commands:

• ./mach buildsymbols
• tar xf obj-aarch64-apple-darwin23.3.0/dist/crashreporter-symbols/XUL/4C4C44A855553144A1B5138B94962AFF0/XUL.dSYM.tar

Comment 4

[[:sergesanspaille]]

The

mozilla::dom::MathMLElement::MapGlobalMathMLAttributesInto()::values case is funny, I'll prepare a small patch.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Perhaps this should be re-run on a non-unified build... A lot of these appear to be much larger than they could possibly be

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #5)

Perhaps this should be re-run on a non-unified build... A lot of these appear to be much larger than they could possibly be

It looks like mozconfig-variant: non-unified happens in "Hybrid" builds labeled "Bp-nu" which only run by default for iOS, but that comes from --disable-unified-build in here?

If this data could be emitted by a taskcluster job via the bloaty-supported csv or tsv output formats, it wouldn't be hard to get searchfox to ingest the data and show the per-file data in the sidebar as proposed in bug 1672307. It could also be possible to ingest symbol data and show a (tree?)table view of the contents of a file which could also include some related details like the relative coverage[1] of the given symbol.

1: Disclaimer: code coverage as ingested by searchfox has been broken since 2024-09-11 so if someone really wanted the coverage data to do some kind of filtering, they would need to fix that too.