Tracing where build time is spent

Jan-Marek Glogowski glogow at
Tue Feb 18 00:32:18 UTC 2020

Am 17.02.20 um 22:02 schrieb Luboš Luňák:
> On Monday 17 of February 2020, Jan-Marek Glogowski wrote:
>>> - 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


Still - the point I was trying to make is that the unpack with your
setup just hits one core and nobody is actually waiting in that
seemingly half-empty timespan in the log. So the build would save ~10s,
if you can cut this time in half. While firebird and nss really are much
slower, due to the non-parallel make.

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

My impression is that general IO operation in Cygwin is slow. We already
know the Win32 make is much faster. Same is documented for git-win in
the wiki for "git status" (native at least a magnitude faster then
Cygwin git -

No idea if native unpack tools could help here and if that is the real
problem, just as for make and seemingly git.

More information about the LibreOffice mailing list