On Sat, Aug 03, 2013 at 01:36:15PM +1000, Nicholas Nethercote wrote: (...) > Even worse, link times are through the roof. I was thrilled when, two > years ago, I switched from ld to gold and linking time plummeted. The > first link after rebooting was always slow, but I could link libxul > back then in about 9 seconds. I haven't measured recently but I'm > certain it's now *much* higher. Even the JS shell, which used to take > hardly any time to link, now takes 10s or more; enough that I often > switch to doing something else while waiting.
The JS engine, having grown to be a lot of C++ instead of being mainly C, also saw its debugging info (DWARF) grow significantly. FWIW, the debug info .so for libmozjs.so at the time of Firefox 15 was 69MB on Linux64, it is 129MB in Firefox 22. More debug info means link time increase, and suggests build increase too (if debug info is bigger, it means either code is bigger, or code is more complex ; or both) > If I could speed up any part of the builds, it would be linking. > Waiting a long time to test a one file change sucks. If you're on linux, you can try --enable-debug-symbols=-gsplit-dwarf. (...) > IWYU tells you the #includes that are unnecessary; it also tells you > which ones are missing, i.e. which ones are being #included indirectly > through another header. I've only bothered removing #includes because > adding the missing ones doesn't feel worthwhile. Sometimes this means > that when you remove an unnecessary |#include "a.h"|, you have to add > a |#include "b.h"| because b.h was being pulled in only via a.h. Not > a big deal. (...) One piece of the puzzle, at least in Mozilla code, is the tendency to #include "Foo.h" when class Bar contains a field of type Foo*, instead of leaving the include to Bar.cpp and forward declare in Bar.h. This certainly contributes to the conflation of the number of includes (most if not all includers of Bar.h don't need Foo.h, and that chains up pretty easily). I don't remember if IWYU tells about those. Does it? (...) > (Another annoying Linux thing is that we have these Mozilla-specific > $OBJDIR/dist/system_wrappers_js/*.h that just #include a system > header. I don't entirely understand what they're for, but they don't > have a #ifndef wrapper and so also get included many times per .cpp > file. I tried adding a #ifndef wrapper but got bustage I didn't > understand. At least these files are tiny.) They are there to reset visibility to default before including the real header and reset it to hidden when returning from the include. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
