Re: Tracing where build time is spent

[Jan-Marek Glogowski <glogow@xxxxxxxxxx>]

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

Ughh.

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 -
https://wiki.documentfoundation.org/Development/BuildingOnWindows#Cygwin_and_git).

No idea if native unpack tools could help here and if that is the real
problem, just as for make and seemingly git.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice