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.devel Subject: Re: Indentation and gc Date: Tue, 14 Mar 2023 15:09:22 +0200 Message-ID: <83ilf3scn1.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <87a60k657y.fsf@web.de> <838rg4zmg9.fsf@gnu.org> <87ttys4dge.fsf@web.de> <83sfebyepp.fsf@gnu.org> <87ttyru4zt.fsf@web.de> <83fsabyb41.fsf@gnu.org> <87mt4jtpqf.fsf@web.de> <83ilf7wi48.fsf@gnu.org> <878rg3wh2f.fsf@localhost> <87a60jtg0z.fsf@web.de> <877cvmumjq.fsf@localhost> <83356aukkh.fsf@gnu.org> <87y1o2t45i.fsf@localhost> <83wn3mt33c.fsf@gnu.org> <873568d7ac.fsf@localhost> <83a60gu0ma.fsf@gnu.org> <87zg8gy81r.fsf@localhost> <837cvku0cg.fsf@gnu.org> <87ttyoy6vy.fsf@localhost> <833568twym.fsf@gnu.org> <87zg8fmrdq.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12201"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 14 14:10:22 2023 Return-path: Envelope-to: ged-emacs-devel@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 1pc4Q1-0002t1-Vs for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Mar 2023 14:10:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pc4PF-0007Hx-9q; Tue, 14 Mar 2023 09:09:33 -0400 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 1pc4PD-0007Hh-9L for emacs-devel@gnu.org; Tue, 14 Mar 2023 09:09:31 -0400 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 1pc4PC-0003w9-PT; Tue, 14 Mar 2023 09:09:30 -0400 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=csM4zviLqCU16jCPPFqnsBOWWAkVgwWQaHjDLdpo3c0=; b=nROX6Mnp4nPp 2rqd1B2RssW8XEe5xV/Lari92GWcRW/b8KI9yK/wP82uJengZE/yB/URNtwITD0BAqva/r60U6eKx Sn4PsoiuSNKS6j8G/NHt9VXr2NUIgh1ODdZmZeJd1QU8Exp+OT/FxZTTvxZbVa5N7IMACPuGhVEp+ J8c3Rnkbo2MArYrHbhEjTG3S9xsJ0eS/JLYjcmalUN5HcLJRxchkgABtHUfB77v3rRl5PNKezO1Ed g59hVR7Q7HdfvO3YvUGQPRT92VCk4zf2VmIiTfOG4x3sUPyAFOYkVMvTJsCDMFba2MWINCBxbNAm1 mpmzxWiLKmi4v83x4I4HsQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pc4PB-0007iF-V0; Tue, 14 Mar 2023 09:09:30 -0400 In-Reply-To: <87zg8fmrdq.fsf@localhost> (message from Ihor Radchenko on Tue, 14 Mar 2023 12:47:29 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304438 Archived-At: > From: Ihor Radchenko > Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org > Date: Tue, 14 Mar 2023 12:47:29 +0000 > > Eli Zaretskii writes: > > >> Noted. Can we measure fragmentation from Elisp? > > > > I think only on glibc platforms, where we have malloc-info. The > > output will need to be post-processed by some code, based on expert > > knowledge of what the numbers mean. > > But can we get the output from Elisp? `malloc-info' docstring says that > the output is done directly to srderr, which we cannot (?) access from > Elisp. Yes. But as I said, I'm not sure this information is useful, unless you are a glibc memory-allocation expert. When we needed to understand these reports, we asked glibc developers for help. > >> Does memory-limit include the fragmented memory segments? > > > > I think it does, although it's system-dependent. It's basically what > > 'top' shows as VSIZE. > > At least, it can indirectly demonstrate the impact of GC threshold onto > Emacs memory footprint. I guess it is what we worry about at the end. > Or does the fragmentation cause other severe effects in addition to > higher memory usage? _Real_ memory fragmentation, if it happens in Emacs, should cause the memory footprint grow all the time without leveling out, and malloc-info should then show that most of the memory is in small chunks that cannot be spliced together. However, I have yet to see a platform where Emacs causes memory fragmentation. Where the system malloc cannot be trusted, we use gmalloc (and in the past used ralloc). Most modern platforms have reliable malloc these days (the single known exception is MSDOS), so this problem largely doesn't exist.