Tracing where build time is spent

[Luboš Luňák]

On Monday 17 of February 2020, Jan-Marek Glogowski wrote:
> Nice tooling. Debian Chromium doesn't have about:tracing, so I used
> https://chromium.googlesource.com/catapult/+/refs/heads/master/tracing/
> with ./bin/trace2html trace.json --output trace.html to analyze the trace.

 There's also https://www.speedscope.app/ , although I have no idea how to 
actually use that.

> From
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Building:
>
> "Ideally, also install gyp and ninja and put them on your path. This is
> recommended, as the build is faster and more reliable."
>
> I had the impression, that just the gyp and ninja build supports
> parallel build currently.

 I've tried it, and yes, it builds so much faster. On Linux it's easy, on 
Windows it seems to require something called MozillaBuild, which is an .exe 
installer of all kinds of Unix tools. I've eventually managed to get nss to 
build with gyp+ninja even on Windows with this, but I'll need to look more 
into it to get it to build with gbuild. Still, I think this is the way to go.

> > - It takes 3 minutes to unpack the 100MiB bzip2 tarball of boost, which
> > unpacks to about 0.5GiB of stuff including generated html docs. It would
> > be a cheap gain to get rid of all doc/ example/ test/ and repack it as
> > .xz .
>
> I don't think this will help and it's a "false positive".

$ time tar xf boost_1_71_0.tar.bz2

real    4m43.122s
user    0m25.077s
sys     1m5.514s

(I have no idea what the Ryzen 7 Windows machine needs all that time for.)

-- 
 Luboš Luňák
 l.lunak at collabora.com