From: phillip.lord@russet.org.uk (Phillip Lord)
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: msys2 building issue
Date: Tue, 10 Apr 2018 13:00:20 +0100 [thread overview]
Message-ID: <87d0z7s23v.fsf@russet.org.uk> (raw)
In-Reply-To: <83zi2rcbqz.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 29 Mar 2018 15:22:28 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: phillip.lord@russet.org.uk (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
about.
Phil
next prev parent reply other threads:[~2018-04-10 12:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-27 21:20 msys2 building issue Phillip Lord
2018-03-29 12:22 ` Eli Zaretskii
2018-04-10 12:00 ` Phillip Lord [this message]
2018-04-10 15:17 ` Eli Zaretskii
[not found] ` <873702sxly.fsf@russet.org.uk>
[not found] ` <83muya3n6s.fsf@gnu.org>
2018-04-10 20:51 ` Phillip Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0z7s23v.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.