bug#45705: [feature/native-comp] Excessive memory consumption on windows 10

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Andrea Corallo <akrl@sdf.org>
>>>> 
>>>> In June we changed the way we store immediate objects in the shared and
>>>> this makes the compilation way lighter on the GCC side (both in time and
>>>> memory).  I've no precise data on this other than the experimental
>>>> observation that compiling all Elisp files in Emacs on 32bit systems is
>>>> not anymore an issue.  This IIUC implies that the memory footprint for
>>>> each compilation is always < 2GB.
>>>
>>> You assume that the compilations are all done serially?  AFAIK, most
>>> people build Emacs with "make -jN", so parallel compilation is an
>>> important use case.
>>
>>> I guess we will have to collect the information about that, if you say
>>> we don't have it now.
>>
>> I'm adding in CC Kevin, IIRC for bug#41077 he used a nice setup to
>> produce quite accurate results on memory footprint during the
>> compilation process.  Perhaps he has time and he's so kind to gather
>> some data on the current state, that would be extremely helpful.
>
> See also bug#41194#20 and bug#41194#28 where I outlined how the
> improvements reduced compilation time and memory usage.
>
> I've dusted off my 32-bit laptop; unfortunately the fan sounds like it's
> in need of… something (probably exorcism, given the noise).

At the moment I think we are interested more in the magnitude order and
also a measure on 64bit would be very interesting.

But you are right I see in bug#41194#20 bug#41194#28 you've already
measured the footprint with the new immediate handling!

IIRC the worstcase was org.el under 600MB.  I think till we get a more
recent measure we should assume this as number (I don't expect huge
changes tho).

Many thanks

  Andrea