1175632 - instrument buildsymbols step

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Chris AtLee [:catlee]]

The buildsymbols step can take a really long time, especially on OSX builds.

I'd like to improve this if possible, but first we should start collecting some metrics about how long we spent generating symbols, e.g. on a per-file basis.

Comment 1

[Mike Hommey [:glandium]]

Last time I checked, the vast majority of the time is spent with one CPU dealing with libxul. The only way I know to improve buildsymbols is to make the dumping process for one file parallelized, and/or make it faster (dump_syms is likely not built to be fast, and could probably be faster. BTW, since it's a host tool, it's not built with optimizations at all, that would be a good start)

Comment 2

[(not currently active) Ted Mielczarek]

Wow, that's terrible. I sanity checked a Linux64 nightly build log to be sure:
04:21:32     INFO -  /builds/slave/m-cen-l64-ntly-000000000000000/build/src/gcc/bin/g++ -o host_dump_symbols.o -c -std=gnu++0x -D_GLIBCXX_USE_CXX11_ABI=0 -MD -MP -MF .deps/host_dump_symbols.o.pp -I/builds/slave/m-cen-l64-ntly-000000000000000/build/src/toolkit/crashreporter/google-breakpad/src/common/linux -I. -I/builds/slave/m-cen-l64-ntly-000000000000000/build/src/toolkit/crashreporter/google-breakpad/src -I../../../../../../dist/include  -I/builds/slave/m-cen-l64-ntly-000000000000000/build/src/obj-firefox/dist/include/nspr /builds/slave/m-cen-l64-ntly-000000000000000/build/src/toolkit/crashreporter/google-breakpad/src/common/linux/dump_symbols.cc

Running dump_syms locally on my Linux debug build shows:
$ time ../debug-mozilla-central/dist/host/bin/dump_syms ../debug-mozilla-central/toolkit/library/libxul.so > /tmp/libxul.sym

real	0m47.292s
user	0m40.005s
sys	0m6.969s

If I add to my mozconfig:
export HOST_CXXFLAGS="-O2 -g"
export HOST_CFLAGS="-O2 -g"

and rebuild, I get:

real	0m22.588s
user	0m15.808s
sys	0m6.489s

...so we should probably make host tools build with some optimization as a first pass. I'm going to file a meta bug for making buildsymbols faster, and then a bug on that.

Comment 3

[Gregory Szorc [:gps]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ef5bd0eb684f

Comment 4

[Gregory Szorc [:gps]]

Attachment: MozReview Request: Bug 1175632 - Record how long each symbol file took to process; r?ted

Bug 1175632 - Record how long each symbol file took to process; r?ted

As part of this an unused import was removed.

Comment 5

[(not currently active) Ted Mielczarek]

Comment on attachment 8665214 [details]
MozReview Request: Bug 1175632 - Record how long each symbol file took to process; r?ted

https://reviewboard.mozilla.org/r/20161/#review20383

This isn't going to measure the time spent running dsymutil on Mac, is it?

::: toolkit/crashreporter/tools/symbolstore.py:613
(Diff revision 1)
> +        t_start = time.time()

I guess pedantically we want to use time.monotonic (which is Python 3 only but has a backport):
https://pypi.python.org/pypi/monotonic/0.4

...but this is probably OK most of the time.

Comment 6

[(not currently active) Ted Mielczarek]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb9bc99aeb0ac9a80fdd6326abbbda6c63be58c6
Bug 1175632 - Record how long each symbol file took to process; r=ted

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/fb9bc99aeb0a

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/fb9bc99aeb0a

Comment 9

[Carsten Book [:Tomcat]]

removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion