From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#37321: 27.0.50; Excessive gc in a use case (el-search) Date: Tue, 17 Sep 2019 01:53:26 +0200 Message-ID: <87r24flrwp.fsf@web.de> References: <87lfv1pm5x.fsf@web.de> <874l1mc01w.fsf@web.de> <87woeidd4g.fsf@web.de> <733d0142-51ee-55df-de0c-cca7c989b370@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="266402"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 37321@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 17 01:54:32 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iA0pD-00178t-MB for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Sep 2019 01:54:31 +0200 Original-Received: from localhost ([::1]:40776 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iA0pB-0006qw-Qc for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Sep 2019 19:54:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52845) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iA0ol-0006qG-4C for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 19:54:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iA0ok-0000d8-2m for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 19:54:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42549) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iA0oj-0000d2-Rr for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 19:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iA0oj-0001jl-Mi for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 19:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Sep 2019 23:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37321 X-GNU-PR-Package: emacs Original-Received: via spool by 37321-submit@debbugs.gnu.org id=B37321.15686780286648 (code B ref 37321); Mon, 16 Sep 2019 23:54:01 +0000 Original-Received: (at 37321) by debbugs.gnu.org; 16 Sep 2019 23:53:48 +0000 Original-Received: from localhost ([127.0.0.1]:51370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iA0oV-0001j8-UR for submit@debbugs.gnu.org; Mon, 16 Sep 2019 19:53:48 -0400 Original-Received: from mout.web.de ([212.227.15.3]:39517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iA0oR-0001ik-QC for 37321@debbugs.gnu.org; Mon, 16 Sep 2019 19:53:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1568678007; bh=YIEOxSEDvA/e+7Jf12ku8avgTQHZEFDJO+MPQAzM5n4=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=eFsG33bu5abRk7nMNZOaADqBbFJdWtyoZ6/mZtw89fjL//EYy3/6IQegzc7XbgdkF 0mfn88KkKT07lpRzAH/F3RW/RP+BDWMFUW1SBDezFafS9hEpCn6SmiDVIj9AL6mIHy FbkyHk6sGckxiOysBtGF6oR5HiW5RJBOYRZ2y4B0= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([94.216.136.59]) by smtp.web.de (mrweb001 [213.165.67.108]) with ESMTPSA (Nemesis) id 0M9oW8-1iKz9y3Qee-00B1yb; Tue, 17 Sep 2019 01:53:26 +0200 In-Reply-To: <733d0142-51ee-55df-de0c-cca7c989b370@cs.ucla.edu> (Paul Eggert's message of "Sat, 14 Sep 2019 01:04:07 -0700") X-Provags-ID: V03:K1:GYEKi5nmC5MLpV2VvqDXoE7eCetSfUBEMGbRiDIlQ9L6Y1M9HuS s3pm1yKhfFCN7uQlI6anf14lzVhKw/GHqbRyRUE2jde/zdst/s4ryyI1o0mBB7fdEzdRTPM qfrYg/+glGfTtNjdMSuqU7wX5pi0htBO2/lboYKE2mbr3lmc+wBf0XST+xMRk3Kf8CU9oCV nxtO5JVwn2lYb9VgC/CbA== X-UI-Out-Filterresults: notjunk:1;V03:K0:rRuTH7slDws=:oCqQAzOxwKU/rIcdyW0fhh 5WnsIWM7sXddz/nXcwQ+2+T2jLHpIQjyegj6hLonNMXzTgzr4zaG2Qm8doME2i/62xf3/mslK ZqffaChBy7Wo9SwHykBBmKz9cTwrAebcOuc/JqFDetaYErboWIZFwoo1RVhzHUkA9k1djtiZM ImEWbCi8CXNAHNWXlm3IUyU0iCAOM7H3bmUxBdFq56X8yE0OjZcJnHAHxAKVjYX42fCXgwVrZ PjkfZUZcaDGFec3D6A/z2nnI5EaqFRCWR5+h+HQV8JMdNMzQEFcFxSoQTlHqivIKSv0dF9c/C pjwmq5nN6ce5XOZZ3Quir+3JCfFAfwi9vP7/+JEyXQgYd6rRpFnEPdPYizqRg738Jt6M0LCwA 4xhXxurFb37h2pPHpHWbDB4cPvJh+BGxcKvnL/PVAR8LplBjgCQ0oDLJnSz+PLhLM1SdvpjQi 80/dktUNgNF54LAhCGg9R+fWxrlcCHm+ZyEA2wtruYvNCbPav7PwgDp4+OWB38W2mH/D6ASjh VG+NuMrt8WQEhHzU7K2bTIL0Y3Mj0mhOoKGLxFlG41ThVss3K3PI3Sb10SZWfEaZG5aVBlE2A wg/c1wYHZzUS2FklAsfLuTXStElM2p4dvkKynd9gwWZDgyYi2SSLNHCs+1/dZGO30WuRJgHru Zsu7CgOkm7auIKgpIaVebXSPPOMu49sdBuCvh5EYXJKRRoWNoLRBrgbg+JRJb64KGq5KC97sO 4hr5kGE5B+omVtmZ/U/mDmlNc31+1CQWHsOho+leCP8fO2geviP4bjQ7tAY2nPG+4eitWTca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:166606 Archived-At: Paul Eggert writes: > > my Emacs seems to have become slower independently from gc. There > > is still a slow down of searching by a factor of at least 3 or so > > that doesn't seem to be related to gc. > > Have you tried turning on profiling to see what the problem might be? For el-searches, yes, I did. But the amounts of time spent were distributed quite evenly between different things, I could not identify a culprit. It looked more like everything got proportionally slower. > I looked into it a bit, and I think the problem is related to this > line in el-search--flatten-tree: > > (gc-cons-percentage 0.8)) ;Why is binding it here more > effective than binding it more top-level? > > That binding is not effective in general, because it causes Emacs to > do most of its computation with gc-cons-percentage equal to 0.8, but a > small amount of it with gc-cons-percentage equal to 0.1 (the default > value). Yeah. Funnily enough I had experimented a lot with where to put this binding. I also had tried what you suggest in your patch. What I currently use looks weird and I don't understand why but in the past it produced the most efficient result - even more efficient than with a more durable binding. Seems this is not true any more. > This is in an attempt to disable most GC. However, the attempt > fails in master because when gc-cons-percentage drops to 0.1 Emacs > does a garbage collection pretty much right away. (In Emacs 26, the > code lucks out because Emacs happens to not look at gc-cons-percentage > during the brief time that it is 0.1, so it doesn't GC.) Ah, ok. > There may be other places in el-search that would benefit from a > change similar to the attached patch, but I didn't investigate this. Yes, I think so. Question: why didn't it help to switch to hash tables? My use case is like this: very frequently I need to collect N (N is variable with an order of magnitude of roughly 0 < N < 100.000 or so) objects in a structure and later perform member tests whether a given element is equal to one of the N. I used to use a list and `member' to implement this. When I use a hash-table that associates the N elements with t instead, and use gethash as member test, do I produce less garbage? That would be good but when using this it didn't lower the amount of time spent in gc. Thanks, Michael.