Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index


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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.