From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Org mode and Emacs Date: Thu, 16 Jun 2022 12:59:40 -0400 Message-ID: References: <87r140yuof.fsf@gmail.com> <875yl9e7zm.fsf@gmail.com> <83czfh12kp.fsf@gnu.org> <87pmjhghu2.fsf@localhost> <835yl910gp.fsf@gnu.org> <87wndndbhq.fsf@gmail.com> <83bkuzznws.fsf@gnu.org> <877d5mqmkh.fsf@localhost> <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17193"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Mattias =?windows-1252?Q?Engdeg=E5rd?= , Eli Zaretskii , Tim Cross , rms@gnu.org, Alan Mackenzie , emacs-devel To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 16 19:08:52 2022 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 1o1szD-0004Kz-Gd for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Jun 2022 19:08:51 +0200 Original-Received: from localhost ([::1]:35920 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o1szB-0002Ba-Tz for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Jun 2022 13:08:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47670) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1sqU-0008Dl-DK for emacs-devel@gnu.org; Thu, 16 Jun 2022 12:59:51 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8303) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1sqQ-00027V-K5; Thu, 16 Jun 2022 12:59:48 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 862CA441667; Thu, 16 Jun 2022 12:59:43 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EA661441665; Thu, 16 Jun 2022 12:59:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1655398781; bh=RE+hlvVrJMncnP4Vj+7JiPx+0n3VDggITuYB/Fu1/Uc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=E+ynqeFc21tWo1EC68UVvTJJyXxSh6M3Ib86DKqgq+q+xFIMGO3HNtoTGDNivkyH9 pYxTKtyV8EVkfa9EPuvRmOTJG4AqDLiLxtgFh+cZJMbnfizV9jzDsUS2sZus4Gprp+ sjY7SaOq+796iO0qQWNxC9rajJBHBh04aI+OuM/3jhRky3YazgigFlCZgF1yEmoAzh yqkZTUYM7O4CluiYyVbnpLHlpEMPyl/KE42nVScRilDZwFEl9D297NHMswwCpV0hXA G/LGjCLDbFlKtMWHCvKiafoEfxJC2/gQ4LdcmuYcV30kf6kUVmO4jvTggOlqD9X62L bUIXJ77ikINWQ== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D267F120278; Thu, 16 Jun 2022 12:59:41 -0400 (EDT) In-Reply-To: <87sfo4epeo.fsf@localhost> (Ihor Radchenko's message of "Thu, 16 Jun 2022 20:58:07 +0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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" Xref: news.gmane.io gmane.emacs.devel:291249 Archived-At: Ihor Radchenko [2022-06-16 20:58:07] wrote: > Mattias Engdeg=E5rd writes: >>> I limited >>> gc-cons-threshold in doc/misc/Makefile.in to 50,000,000, not >>> most-positive-fixnum. >> >> Some timings for the export to .texi (old machine, optimised build, byte= code only): >> >> | gc-cons-threshold | time | >> |----------------------+------| >> | 800000 | 14.1 | (default value) >> | 25000000 | 6.2 | >> | 50000000 | 5.7 | >> | 100000000 | 5.7 | >> | most-positive-fixnum | 5.1 | >> >> thus Eli's choice is very good, and we really should do something about = that GC of ours. > > I am wondering if there is a "universal" value suitable for one-off Emacs > batch invocations. I doubt that's the case, but of course we should try and use values that work "overall best" on average. Maybe we should revisit the current knobs and their default values. Currently the two important knobs we have are: gc-cons-threshold gc-cons-percentage Maybe it's time for some benchmarks with various values for these knobs to see if the values we're using now are "good enough" or might need to be changed. We could also try and be bit more discerning. E.g. currently when the program is in a phase where it builds a lot of new data-structures, we run the GC everytime some amount of new memory has been allocated, but presumably almost none of those objects have died yet (we're still building the overall datastructure) so the GC will be a pure waste of time. OTOH in other phases the code allocates objects which are used only temporarily, in which case it's beneficial to run the GC somewhat frequently to avoid growing our heap unnecessarily (and suffering fragmentation as a result). It's hard to know beforehand whether a GC will be useful or not, tho. But maybe we can find good heuristics. E.g. have something like a `gc-cons-percentage` which depends on how much garbage we collected in the last GC: if a GC doesn't collect any garbage (or very little of it), it's a sign that we're in a phase where running the GC is not very useful so we should wait a bit more until the next GC, whereas if the GC collected a fair bit of garbage, it's a sign that we're in a phase where running the GC is beneficial and we can run it a bit more often. Stefan