Re: Tracing where build time is spent

I have to drop the test keys from xmlsecurity/qa from my keyring... so
once more:

Am 16.02.20 um 15:33 schrieb Luboš Luňák:
>  I've pushed https://gerrit.libreoffice.org/c/core/+/88754 , which allows 
> viewing what actually happens during building. Exact instructions are in 
> https://cgit.freedesktop.org/libreoffice/core/tree/solenv/gbuild/Trace.mk . 
>
>  At http://ge.tt/9z4s0J13 I've uploaded a trace 
> of './autogen.sh --enable-dbgutil --disable-java && make' Windows build on 16 
> HT core Ryzen 7 that takes about 70 minutes, viewable using the 
> chrome://tracing URL in Chromium.

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.

>  A couple of observations:
>
> - About 9 minutes are spent building only nss and firebird, both apparently 
> doing -j1 builds, and nss blocks most of LO sources, and nss itself is 
> blocked by python3. IIRC somebody has already tried to do something about 
> these and didn't manage. Nss's build page says that the recommended build is 
> actually using some Mozilla build tool instead of autotools, has somebody 
> tried that?

I fixed larger parts of the NSS parallel build in here:
https://gerrit.libreoffice.org/c/core/+/74751

My originally small patch turned out to become a whole patchset over
time. It's still there and was working for the latest NSS upload. As you
can see from the patches, I handle NSS in a separate git repo. I'm
normally building my local Windows and Linux builds with it. But that's
not a good indicator, as the build isn't that parallel here.

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 also found these upstream bugs:

Upstream also has multiple bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=290526
- https://bugzilla.mozilla.org/show_bug.cgi?id=836220

I didn't yet try to upstream the patches. On NSS IRC nobody replied when
I asked about it.

> - 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".

In the graph this is ~3m on one of the 16 threads of that build. All the
other threads are busy doing other LO build stuff in parallel most of
the time. And 5 are building externals during the whole UPK gap.

The main problem of the graph: you don't see the parallel external
builds spreading out jobs. IMHO as long as there is one parallel
external build running, the machine is actually busy parallel building
that external.

Which AFAIK leaves the NSS and firebird builds, as you already observed.

Jan-Marek