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

Previous Next

Full log

Message #44 received at 45705 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, edouard.debry <at> gmail.com,
 45705 <at> debbugs.gnu.org
Subject: Re: bug#45705: [feature/native-comp] Excessive memory consumption
 on windows 10
Date: Sat, 09 Jan 2021 19:41:09 +0000

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

> Andrea Corallo <akrl <at> sdf.org> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Andrea Corallo <akrl <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.