From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Identifying sources of allocations in a toy Mandelbrot package Date: Fri, 19 Jan 2024 17:44:48 +0200 Message-ID: <83o7dhuy33.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23280"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 19 16:45:27 2024 Return-path: Envelope-to: geh-help-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 1rQr3e-0005oQ-J7 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 19 Jan 2024 16:45:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQr38-0007yo-2Z; Fri, 19 Jan 2024 10:44:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rQr36-0007yW-Dt for help-gnu-emacs@gnu.org; Fri, 19 Jan 2024 10:44:52 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rQr36-0000A1-4s for help-gnu-emacs@gnu.org; Fri, 19 Jan 2024 10:44:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/1a57ZROH1P/Tp6mU0god1x/ZL2pdo/WwtgAQzjWN2c=; b=VXOlIdoOkz75 cTR3THPJ1VL2GkHUUu+3rrZDhPyYXifjXGHjj9cNtVNTMa1uCL2lR3bA2JtJ/Q46sIxpVLMvRNRsM PYGIxegfoT5ktSW0xB2FcsrcQa/qY7CsihkWEoobIJNirBXOPQQPQcdk20z38UuXOyB0eZc99dDnb COQhxXTPLXZyeQdfsUsbZDmNFISoKp2wXak/rB6TwhKRJzOzGQN2xcw9QFV/u6QUEGgfGw2VgAyIE oOBomBgK1nnB8RABBlnV+SveG1OD99+kyiRePkhS+MJ/5lu6Pm/6lmOjAU093b49xilKexAbJ/7cb Gidqg0YbGRfGss9DTlXNDw==; In-Reply-To: (message from Psionic K on Fri, 19 Jan 2024 18:19:55 +0900) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:145755 Archived-At: > From: Psionic K > Date: Fri, 19 Jan 2024 18:19:55 +0900 > Cc: incal@dataswamp.org, Eli Zaretskii > > Most importantly to my question, how can I identify sources of consing > without just knowing which functions and macros pathologically cons? Insert calls to garbage-collect, and look at the value it returns. > Is there a way to allow usage of stack by the byte or native compiler? Lisp objects are not allocated on the stack. > > and a lot of nested iteration > > I would have expected this to consume only stack memory Any temporary Lisp objects will allocate memory. Their references will be on the stack, but the objects themselves will be on the heap. > Perhaps concerning is that Emacs continues to consume the same > resident memory, about 2.1GB, indefinitely after the first run. Is > this simply expected from a sprinkling of objects that Emacs cannot GC > and therefore never give back memory? The memory is released and available for subsequent allocations, but not necessarily given back to the OS. Whether and when to give memory back to the OS depends on the internals of the C library your Emacs is using. > Is this unique to floating points? Do I still have latent consing in > this version? Thanks in advance. I don't think I understand what you are asking here, please elaborate.