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: Sun, 12 Mar 2023 17:13:27 +0200 Message-ID: <83wn3mt33c.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <20230310110747.4hytasakomvdyf7i@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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33453"; 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 Sun Mar 12 16:14:46 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 1pbNPK-0008TS-8a for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Mar 2023 16:14:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbNOP-0001S3-9y; Sun, 12 Mar 2023 11:13:49 -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 1pbNOL-0001Ra-AK for emacs-devel@gnu.org; Sun, 12 Mar 2023 11:13:46 -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 1pbNOJ-0005c8-HS; Sun, 12 Mar 2023 11:13:43 -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=7quXXeoYgvv6ohns83P8uTa5diADVCjku9eOsXzhDlw=; b=QUUw1sNUI1WJ SpnuGcy7pya0rX5+x/3ZeBhAjEA234KoZyPdXdARzZfiAix+z2ORy6I1aX+bHSs9o+n2TELZRfybP 4SNXUopEO5geZfxOlPRYZpDHDxryR8m2V335/Xt4fPi7tNOW09jBB/QaEQ6Lupn7oK/qex2BoR2jn GY2dugS0t13SkjZzh5lG24QbbFmS00s2aLyc5/6EsCgJr7gSQDT5s11SuHEbzcD0qPvcvAOyHQQrd K7Df+wuq2kc86HQead8GMfFn0loapKi1FyF8jwCB9JZgDPeuFjXmI/V9SrDDFpBY7l18nUdnToQXH TrW+NfeP4soolenzPGWfYA==; 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 1pbNOF-0004Nz-TO; Sun, 12 Mar 2023 11:13:42 -0400 In-Reply-To: <87y1o2t45i.fsf@localhost> (message from Ihor Radchenko on Sun, 12 Mar 2023 14:50:33 +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:304375 Archived-At: > From: Ihor Radchenko > Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org > Date: Sun, 12 Mar 2023 14:50:33 +0000 > > Eli Zaretskii writes: > > >> I think that (2) is the most important factor for real world scenarios > > > > Not sure why you think so. Maybe because I don't have a clear idea > > what kind of fragmentation you have in mind here. > > I meant that as long as gc-cons-threshold is much lower (10x or so) than > heap size (Lisp object part), we do not need to worry about (1). Only > (2) remains a concern. Your gc-cons-threshold is 250 MiB. If it's below 0.1 of the size of Lisp data, does that mean you 2.5 GiB or more of Lisp data in your sessions? That's a lot. I have less than 300 MiB, for comparison, and this is a session that runs for 25 days non-stop, and has a 520 MiB memory footprint. > 10% also means that 800k gc-cons-threshold does not matter much even > with emacs -Q -- it uses over 8Mb memory and thus gc-cons-percentage > should dominate the GC, AFAIU. How did you measure those 8Mb? On my system, memory-report in "emacs -Q" shows less than 2 MiB in object memory. > Note that my proposed 100Mb gc-cons-threshold limit will correspond to > 1Gb live Lisp objects. For reference, this is what I have now (I got the > data using memory-usage package): > > Total in lisp objects: 1.33GB (live 1.18GB, dead 157MB) We need to align and calibrate our measurement means: what does memory-report tell about object memory in that session? 1.18 GiB sounds a lot. > > Correction: it is _your_ init.el. We need similar statistics from > > many users and many different usage patterns; only then we will be > > able to draw valid conclusions. > > Sure. Should we formally try to call for such benchmarks? Yes! > > Actually, Emacs tries very hard to avoid fragmentation. That's why it > > compacts buffers, and that's why it can relocate buffer text and > > string data. > > Indeed. But despite all of the best efforts, fragmentation increases if > we delay GCs, right? Not IME, no. That's why the memory footprint of a typical long-running session levels out.