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.bugs Subject: bug#46326: 27.1.50; Excessive memory allocations with minibuffer-with-setup-hook Date: Fri, 05 Feb 2021 17:58:27 +0200 Message-ID: <83a6sipkv0.fsf@gnu.org> References: <62c490ed0d8d24d8b259ac1ba55ea79e@mendler.net> <83eehuppx6.fsf@gnu.org> <4aab2ef892b1df213ca67210021bcd47@mendler.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10757"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46326@debbugs.gnu.org To: mail@daniel-mendler.de Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 05 16:59:16 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 1l83Vq-0002eO-RC for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Feb 2021 16:59:14 +0100 Original-Received: from localhost ([::1]:43108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l83Vp-000606-U7 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Feb 2021 10:59:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l83Ve-0005rn-M4 for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 10:59:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:32985) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l83Ve-0001Mi-Dn for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 10:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l83Ve-0005j2-Bk for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 10:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Feb 2021 15:59: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.161254071121973 (code B ref 46326); Fri, 05 Feb 2021 15:59:02 +0000 Original-Received: (at 46326) by debbugs.gnu.org; 5 Feb 2021 15:58:31 +0000 Original-Received: from localhost ([127.0.0.1]:44531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l83V8-0005iL-RO for submit@debbugs.gnu.org; Fri, 05 Feb 2021 10:58:31 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l83V7-0005i8-DV for 46326@debbugs.gnu.org; Fri, 05 Feb 2021 10:58:29 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46937) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l83V1-00012J-G5; Fri, 05 Feb 2021 10:58:23 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3098 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l83V0-0005aB-Aq; Fri, 05 Feb 2021 10:58:23 -0500 In-Reply-To: <4aab2ef892b1df213ca67210021bcd47@mendler.net> (mail@daniel-mendler.de) 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:199393 Archived-At: > Date: Fri, 05 Feb 2021 16:20:13 +0100 > From: mail@daniel-mendler.de > Cc: 46326@debbugs.gnu.org > > > Please show information about the memory consumption. (The so-called > > "memory profile" doesn't actually measure memory consumption at all, > > it just uses memory allocation calls as a poor-man's profiling > > signal.) > > Yes, I am aware. I am not saying that live memory is the problem, > but the excessive amount of allocations is a problem, which creates > unnecessary garbage collector pauses. Therefore I can also not show > you a profile of the memory consumption, since it is not relevant. 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. > > What exactly caused you to run the profiler? is the code slow or > > something? If so, the problem may be something other than memory > > consumption. > > Yes, it is slow. Add-hook performs unnecessary allocations causing > pauses. After replacing the minibuffer-with-setup-hook default > implementation with my workaround the memory allocations went away > and the command is much faster. The add-hook calls do not appear in > the memory profile anymore. See the comment > https://github.com/minad/consult/issues/193#issuecomment-770650405. 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?