[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: msys2 building issue

From: Phillip Lord
Subject: Re: msys2 building issue
Date: Tue, 10 Apr 2018 13:00:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Phillip Lord)
>> Date: Tue, 27 Mar 2018 22:20:34 +0100
>> x86_64
>> no-deps zip    17min
>> Deps-zip       3min
>> installer      25min
>> i686
>> no deps zip    31min
>> deps zip       47min
>> installer      61min
>> So, the installer is really slow to build (probably because of the
>> compression I guess). But the second i686 step is really slow,
>> especially the building the zips and installer.
> Does this happen only when building both the 64-bit and the 32-bit
> zips?  What if you build only the 32-bit one -- do you get the same
> slow times?
> My next suspect is the way MSYS2 lets you build 32-bit binaries.  I
> know nothing about that, all I see is that you set 2 environment
> variables, but could that cause Bash or Make or some other component
> to run out of memory due to a bug or a memory leak?

I've tested this out since. And I am having a hard time making head nor
tail of it. Building on it's own, the i686 will build fast
enough. Building x86_64 sometimes give very inconsistent behaviour
between the two builds (with the second slower). I could, of course,
build the x86 and i686 separately, but I want to launch the build once
and let it finish.

I've had occasions when the build time goes up to many hours.

>> I don't think this is the Emacs build per se; it looks to me like a
>> memory leak; the build process just gets slower and slower. In fact,
>> I've had to reduce the parallalism of make or the whole process crashes
>> with a resource allocation error.
> Which program reports the error?
>> But Process Manager reports that the VM has memory left.
> What does Task Manager say about memory consumption of the various
> programs involved in the build, like Bash, Make, and Python?  Do you
> see their memory growing to values that are unreasonably large?
> The slow-down could be caused by memory consumption, so it's possible
> the actual problem is with memory, not with slow builds.

Actually, no Task Manager reports that CPU is 100%, memory is between 50
and 70%.

I'm coming to the conclusion that it's an oddity of the VM
infrastructure. I think it's going to be hard to test out further,
because the slow build makes experiments a bit of a PITA.

Never mind, even if it is slow it always seems to build now that I am
using only dual threaded build. I guess that is ultimately all I care


reply via email to

[Prev in Thread] Current Thread [Next in Thread]