From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Micha=c5=82_Kondraciuk?= Newsgroups: gmane.emacs.help Subject: Re: Question about memory usage Date: Tue, 3 Apr 2018 19:57:34 +0200 Message-ID: <690641bc-fc49-922a-26bd-6f92322d0cc0@zoho.com> References: <83sh8c6byb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1522778193 26393 195.159.176.226 (3 Apr 2018 17:56:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Apr 2018 17:56:33 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Apr 03 19:56:29 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3QAX-0006it-2L for geh-help-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 19:56:29 +0200 Original-Received: from localhost ([::1]:52799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3QCa-00065y-GQ for geh-help-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 13:58:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3QC4-00065C-VW for help-gnu-emacs@gnu.org; Tue, 03 Apr 2018 13:58:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3QC0-0007j4-SZ for help-gnu-emacs@gnu.org; Tue, 03 Apr 2018 13:58:05 -0400 Original-Received: from sender-pp-092.zoho.com ([135.84.80.237]:25460) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f3QC0-0007hg-Ni for help-gnu-emacs@gnu.org; Tue, 03 Apr 2018 13:58:00 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:from:cc:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=o7SmU2UfYa+xsgfYuICIUakC28l3XkD3iYiZQ6hHReUupup+mU5EeBwg5EWsiY3BbTwnNj7gvPmp 6ob1b4kozRgdNLrHAQQttgx+1cdFwenfFu1IRTxzhRu/oMyR12WO Original-Received: from [192.168.0.87] (84-10-171-192.static.chello.pl [84.10.171.192]) by mx.zohomail.com with SMTPS id 1522778262065494.634873740809; Tue, 3 Apr 2018 10:57:42 -0700 (PDT) In-Reply-To: <83sh8c6byb.fsf@gnu.org> Content-Language: en-US X-ZohoMailClient: External X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 135.84.80.237 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:116325 Archived-At: On 04/03/2018 08:28 AM, Eli Zaretskii wrote: >> From: Michał Kondraciuk >> Date: Mon, 2 Apr 2018 13:57:26 +0200 >> >> Basically, when I run the sexp below in emacs -Q, Emacs keeps allocating >> a lot of memory. In 10 minutes, it goes from 18 MB to over 200 MB. >> >> (while t >> (with-temp-buffer >> (setq buffer-undo-list nil) >> (insert "a"))) >> >> >> Calling garbage-collect afterwards or even inside the body of the loop >> doesn't help (except the loop obviously runs slower, so after 10 >> minutes, Emacs uses ~100 MB of memory). > > What do you mean by "afterwards"? The while-loop never ends, so > there's no "afterwards" AFAIU. Am I missing something? You're right, I meant after I stop the loop with C-g. > To answer your question: yes, I think this is expected, given that you > set buffer-undo-list to nil (what is the purpose of that, btw?). No purpose, but some external packages display information in a way similar to this sexp, where undo information is also recorded (needlessly): (with-current-buffer (get-buffer-create "info") (let ((inhibit-read-only t)) (erase-buffer) (insert "info")) (setq buffer-read-only t) (display-buffer (current-buffer))) I tested it in a loop (but also killed the "info" buffer in each iteration) and Emacs also keeps allocating memory, as with (with-temp-buffer (setq buffer-undo-list nil) ...). Obviously normally this isn't a problem because you won't run this code in a loop, but if you leave Emacs open for a long time and run this sexp as part of some command many times, memory can accumulate (I think, it's why I asked if Emacs will finally free this unused memory). > When Emacs ends up requesting more memory from the OS, it usually > doesn't release that memory when it is no longer needed, but keeps it > in the process's address space and reuses it if/when it needs more > memory. But shouldn't Emacs reuse the memory from previous loop iteration instead of allocating it? Also, if the sexp is modified like this, Emacs memory usage is at the same level: (while t (with-temp-buffer (insert "a") (setq buffer-undo-list (list (cons (point-min) (point-max))))))