From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: mail@daniel-mendler.de Newsgroups: gmane.emacs.bugs Subject: bug#46326: 27.1.50; Excessive memory allocations with minibuffer-with-setup-hook Date: Fri, 05 Feb 2021 17:10:46 +0100 Message-ID: <631e918824625b8bde45b69664347398@mendler.net> References: <62c490ed0d8d24d8b259ac1ba55ea79e@mendler.net> <83eehuppx6.fsf@gnu.org> <4aab2ef892b1df213ca67210021bcd47@mendler.net> <83a6sipkv0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18095"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.2-git Cc: 46326@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 05 18:54:48 2021 Return-path: Envelope-to: geb-bug-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 1l85Jg-0004bc-Ni for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Feb 2021 18:54:48 +0100 Original-Received: from localhost ([::1]:36602 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l85Jf-0000Qf-K7 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Feb 2021 12:54:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l84aR-0006r6-33 for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 12:08:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33072) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l84aQ-0007Gt-SP for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 12:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l84aQ-0007QV-NL for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 12:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: mail@daniel-mendler.de Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Feb 2021 17:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46326 X-GNU-PR-Package: emacs Original-Received: via spool by 46326-submit@debbugs.gnu.org id=B46326.161254483728474 (code B ref 46326); Fri, 05 Feb 2021 17:08:02 +0000 Original-Received: (at 46326) by debbugs.gnu.org; 5 Feb 2021 17:07:17 +0000 Original-Received: from localhost ([127.0.0.1]:44614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l84Zg-0007P8-AC for submit@debbugs.gnu.org; Fri, 05 Feb 2021 12:07:16 -0500 Original-Received: from server.qxqx.de ([178.63.65.180]:54590 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l83h5-00060B-6t for 46326@debbugs.gnu.org; Fri, 05 Feb 2021 11:10:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=zzO9clrWwHQ4JujdUBj+Hdxf/+YBQ3GewtnpUhM+u6A=; b=GC5yAk6+j17It3mnZparYRgvxl/x3aNVZrQZs7yti53qTL+9XHVLiaSgjxJhvsD05OyQp3/LizCiG4PGJoLOxishsHyCG5qgOBDhmqxhk3gQ/Rl3ctykChMohlvAIclM0sH//8qkySSyXWuMgrnKEG9aaXO0+8ntYM+282HdyiY=; In-Reply-To: <83a6sipkv0.fsf@gnu.org> X-Sender: mail@daniel-mendler.de X-Mailman-Approved-At: Fri, 05 Feb 2021 12:07:15 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:199395 Archived-At: Hello Eli! > If you are saying that the Lisp code in question conses too many > objects unnecessarily, then the solution is to modify the code to cons > less objects. That doesn't necessarily indicates the existence of a > bug in Emacs, certainly not with its memory management. My code certainly *does not allocate* too much. It is the add-hook implementation or more precisely the minibuffer-with-setup-hook implementation which is responsible for the excessive allocations. For this reason this is an upstream bug. In my workaround, I am replacing the upstream version of minibuffer-with-setup-hook with my own version to show the difference. This does not mean that I consider the problem to be gone. I rather decided to report the problem instead. > So if you already have a solution for the problem, what is it that you > want us as Emacs maintainers to investigate and fix here? I am actually not sure what the proper upstream fix is. I see the following options. 1. Replace minibuffer-with-setup-hook with my version if you think my version is better and an acceptable fix. 2. Investigate the reasons why add-hook with priorities somehow copies large closures during sorting. This is unacceptably costly. To give you a better picture of the overall situation - it looks like this: (minibuffer-with-setup-hook (lambda () ...large closure...) (minibuffer-with-setup-hook (lambda () ...another large closure...) (minibuffer-with-setup-hook (:append (lambda () ...and yet another one...)) (completing-read ...)))) The bug is that the large closures are copied for some unknown reason in the add-hook calls which I am not controlling as a library author. My replacement adds the hooks in another way, by creating a symbol+fset instead of putting the lambda directly in the minibuffer-setup-hook variable. Daniel