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: Eager garbage collection Date: Wed, 18 Nov 2020 11:52:26 -0500 Message-ID: References: <20201118002050.16426-1-sbaugh@catern.com> <87wnyik801.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24796"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Spencer Baugh , Andrea Corallo To: Andrea Corallo via "Emacs development discussions." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 18 17:53:16 2020 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 1kfQho-0006M9-Op for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Nov 2020 17:53:16 +0100 Original-Received: from localhost ([::1]:57554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfQhn-00026E-Pg for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Nov 2020 11:53:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfQh9-0001eb-Sg for emacs-devel@gnu.org; Wed, 18 Nov 2020 11:52:35 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55436) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfQh4-0006am-H3 for emacs-devel@gnu.org; Wed, 18 Nov 2020 11:52:34 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5244C80479; Wed, 18 Nov 2020 11:52:28 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F3393806F7; Wed, 18 Nov 2020 11:52:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1605718346; bh=U3D+lPwijrVI7NOGF8FVyDQ2CSHUJR7SxfV4BMRYZas=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=JDb+IbBghS4yOjDq28v1ii+Rf+QDJyY/yX2ijButumFDKFrMhDqjHDvR7DyaRRzUN 5FiFYC0vEV6XJg8C6e6T9HqpuAOmjOQl6s22RdJ+5KnBFJiFAjrhPsIdfqBYPi8v+n 8wjMnn+fIVqZM4CORu6e3cNjORPXneMCHwP8GKxFcJKovWGWgNzjdGZ2ZwfW//f/B4 NgTXXH357tDmeWhsTSf2WcL3I0wQovGiZ/Q/ztighxO4v0pXjD3D1Lg5pXymN9ZgIs YiMkrPdccKgmQs9DrAnpP6PfSq94oFnh2SqoetRgTIKU1LC/gFJTyRGhJiqUDI0MG5 bIN3eaVxyskQw== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C4105120325; Wed, 18 Nov 2020 11:52:26 -0500 (EST) In-Reply-To: (Andrea Corallo via's message of "Wed, 18 Nov 2020 15:47:30 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/18 11:52:28 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] 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 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:259359 Archived-At: > Setting a lower threshold there also prevents functions that may be > executed by timers to leave the heap with garbage just before the user > start the next command. This is risky, tho, because a low threshold will increase the proportion of time spent in GC, which could negatively impact the performance of process-filters. I do think it is good to move as much of the code to Elisp. But the patch Spencer sent only has 2 small parts in C: the gc-time tracker and the gc-maybe function. We could move the gc-time tracker to Elisp (and it could be a good idea to do so, since I can imagine getting fancier in there. E.g. instead of tracking the actual GC time, we could track the "time relative to heap size" which might allow us to better predict the time taken by the next GC), but we'd still need some changes to the C code for example so that `post-gc-hook` gets access to the elapsed time of the last GC. For gc-maybe, we could arguably code it all in Elisp, indeed, as: (defun gc-maybe (factor) (let ((gc-cons-threshold (/ gc-cons-threshold factor)) (gc-cons-percentage (/ gc-cons-percentage factor))) (eval (+ 1 1)))) ;; This internally calls the `maybe_gc` C function. The `eval` part is quite hackish, tho, and the workings depend on exactly when those gc-cons-* settings take effect which is not documented either. In contrast the C version is clear and direct, so I think I'm pretty happy with the C version. Stefan