From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Newsgroups: gmane.emacs.bugs Subject: bug#45705: [feature/native-comp] Excessive memory consumption on windows 10 Date: Sat, 09 Jan 2021 18:26:46 +0100 Message-ID: <87im86c97t.fsf@gmail.com> References: <87y2h5hjve.fsf@gmail.com> <831revjyja.fsf@gnu.org> <83turrif53.fsf@gnu.org> <83lfd2ilwf.fsf@gnu.org> <83y2h2gw9v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6147"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: edouard.debry@gmail.com, 45705@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 09 18:27:25 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kyI1M-0001Pv-An for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Jan 2021 18:27:24 +0100 Original-Received: from localhost ([::1]:42100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kyI1L-0007VR-5e for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Jan 2021 12:27:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41916) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyI10-0007U1-8H for bug-gnu-emacs@gnu.org; Sat, 09 Jan 2021 12:27:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40993) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kyI10-0002Ko-1H for bug-gnu-emacs@gnu.org; Sat, 09 Jan 2021 12:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kyI0z-00035E-To for bug-gnu-emacs@gnu.org; Sat, 09 Jan 2021 12:27:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Jan 2021 17:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45705 X-GNU-PR-Package: emacs Original-Received: via spool by 45705-submit@debbugs.gnu.org id=B45705.161021321911842 (code B ref 45705); Sat, 09 Jan 2021 17:27:01 +0000 Original-Received: (at 45705) by debbugs.gnu.org; 9 Jan 2021 17:26:59 +0000 Original-Received: from localhost ([127.0.0.1]:52536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kyI0x-00034t-8z for submit@debbugs.gnu.org; Sat, 09 Jan 2021 12:26:59 -0500 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:55201) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kyI0s-00034S-Kg for 45705@debbugs.gnu.org; Sat, 09 Jan 2021 12:26:58 -0500 Original-Received: by mail-wm1-f43.google.com with SMTP id c133so10288370wme.4 for <45705@debbugs.gnu.org>; Sat, 09 Jan 2021 09:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=p3RbSEpgcVqcaRM+sho17m+rQzwp9qQmVHEaG0tV+8E=; b=LzikEmPfaMA8FZph1WMiCwbnuHdUccG9Osi4SAkQaLRiNPLYZh2cH7xdTZ6SR1gphP V/tU6jwvmHeqH6/cX/+5WMiwk9TNTHl63LPnHNuTcvRlnebfj8y0B5Ec/3as6i9td1Jp A21HlDgKmJ84whmWyiIzYCbOzsKHyS3tX8n6KS9sQAR9Odq9EPneVk/mqcbDemR9TEpe 8DtYoVTS38WnmzWG3azYZQAzRRXFzzOR+lq/3M9DSew7ouXcu8uiqVYrnkjKGsAe01iE j13I+KJiuec66mrCDq1gZERByun7GbeN6jxbpoHDg6/ywN0aFh2x8ifX7BmU6uj1bhpP TuCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=p3RbSEpgcVqcaRM+sho17m+rQzwp9qQmVHEaG0tV+8E=; b=eEwVXQuw5yhEzx0JpSva6VXy8/sooksTwjxHoaJBTdaSNozNlUHbW3q5ax/f9ZzwmN z3cOqL+W0ztDd/RFqbYH77qWhctvYqmvUOFHXZKnaMMYDfhkz/kLdXSw3ImTId5wRS9k fQyacal8GaaQLsyvcBd6QFcf8hkUxqKlUDB3Ss+fzCmeQgzhoST8Xp8vThwC1+QHh+fe EPEg7do45jvoLHvX+4XrWaP0lHbWhrmkEsQqL+gX28xeKPxXh1hO70N998gRN5chd3QM OsLsfB6bsoreQuzYiVUNfE/naddefQ3n4xV3nLEpIl43aP3NmAViOJlgHVDDZhBDZ4cY 1dnQ== X-Gm-Message-State: AOAM531REnwJZYkaG+h01g6qX1t0T5Ed1cjPlx9jio09aDSCy2r3wrka tKf8TpbZsmacO1198EyvTXRCQ0iDkPLFH8in X-Google-Smtp-Source: ABdhPJz380Pp/cGH6Baq4VxLoEuRkjsiPsSYZEAXsYq2laUiz20L3FAwnY2rPzQ9X/U5s4Pa1m2jdw== X-Received: by 2002:a1c:c254:: with SMTP id s81mr8048005wmf.132.1610213208414; Sat, 09 Jan 2021 09:26:48 -0800 (PST) Original-Received: from my-little-tumbleweed ([2a01:e0a:20e:d340:922b:34ff:fe95:9aed]) by smtp.gmail.com with ESMTPSA id m21sm15979328wml.13.2021.01.09.09.26.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Jan 2021 09:26:47 -0800 (PST) In-Reply-To: (Andrea Corallo's message of "Sat, 09 Jan 2021 12:37:54 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:197560 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andrea Corallo writes: > Eli Zaretskii writes: > >>> From: Andrea Corallo >>>=20 >>> 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=E2=80=A6 something (probably exorcism, given the noise). Until I figure that out, here are the (very hacky) scripts I used to measure and plot the RAM usage, in case someone else wants to take some measurements: - ./monitor.sh $PID finds the most RAM-consuming process among $PID and its children, and logs its memory usage (VSZ and RSS) and its command-line. (Logs are collected every 10 seconds; this probably needs to be reduced for faster machines) - ./plot.py uses matplotlib to make graphs out of these measurements; it attempts to replace the command line with the less-verbose diagnostics from "make". - My workflow was to start an emacs session, run M-x compile RET make, then ./monitor.sh $PID_OF_EMACS_SESSION. (PARENT_RE in plot.py should match the command-line of this parent session; its RAM consumption is then labeled as "noise floor" on the graph. This serves no real purpose and should be removed; monitor.sh should be amended to filter the parent session out of monitored PIDs, with some error control to handle the lack of child processes when compilation is finished.) - There are some hardcoded things to tweak at the bottom of plot.py, e.g. how long should a child process last for it to have a label on the graph. --=-=-= Content-Type: application/x-shellscript Content-Disposition: attachment; filename=monitor.sh Content-Transfer-Encoding: base64 IyEvYmluL2Jhc2gKCnNldCAtZXUKCm91dD0kKGRpcm5hbWUgJDApL21vbml0b3IubG9nCnBhcmVu dD0kMQoKcmVjdXJzZSAoKQp7CiAgICBlY2hvICQxCiAgICBmb3IgY2hpbGQgaW4gJChwcyAtbyBw aWQ9IC0tcHBpZCAkMSkKICAgIGRvCiAgICAgICAgcmVjdXJzZSAkY2hpbGQKICAgIGRvbmUKfQoK d2hpbGUgc2xlZXAgMTAKZG8KICAgIGRhdGUgKyIlRi0lVCIgPj4gJHtvdXR9CiAgICBwcyBvIGNw dXRpbWVzPSx2c3o9LHJzcz0sYXJncz0gLS1zb3J0PS12c3ogcCAkKHJlY3Vyc2UgJHtwYXJlbnR9 KSB8IGhlYWQgLTEgPj4gJHtvdXR9CiAgICBmcmVlID4+ICR7b3V0fQogICAgZWNobyA+PiAke291 dH0KZG9uZQo= --=-=-= Content-Type: text/x-python; charset=utf-8 Content-Disposition: attachment; filename=plot.py Content-Transfer-Encoding: quoted-printable #!/usr/bin/env python3 from datetime import datetime, timedelta from pathlib import Path import re import matplotlib from matplotlib import pyplot from matplotlib.dates import DateFormatter, HourLocator, MinuteLocator from matplotlib.ticker import EngFormatter MONITOR_RE =3D re.compile('\n'.join(( '(?P