From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#37321: 27.0.50; Excessive gc in a use case (el-search) Date: Sat, 14 Sep 2019 01:04:07 -0700 Organization: UCLA Computer Science Department Message-ID: <733d0142-51ee-55df-de0c-cca7c989b370@cs.ucla.edu> References: <87lfv1pm5x.fsf@web.de> <874l1mc01w.fsf@web.de> <87woeidd4g.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------D4D810EA17EDE6283E48FC8C" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="171738"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: 37321@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 14 10:05:14 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 1i933R-000iYc-F1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Sep 2019 10:05:13 +0200 Original-Received: from localhost ([::1]:48966 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i933P-0008Pd-Iw for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Sep 2019 04:05:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60499) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i933H-0008PR-Ie for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 04:05:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i933G-0005Ce-Eo for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 04:05:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36996) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i933G-0005CY-AJ for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 04:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i933G-0007nt-39 for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 04:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 08:05:02 +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.156844825629936 (code B ref 37321); Sat, 14 Sep 2019 08:05:02 +0000 Original-Received: (at 37321) by debbugs.gnu.org; 14 Sep 2019 08:04:16 +0000 Original-Received: from localhost ([127.0.0.1]:45816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i932W-0007mm-15 for submit@debbugs.gnu.org; Sat, 14 Sep 2019 04:04:16 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:57398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i932U-0007mZ-On for 37321@debbugs.gnu.org; Sat, 14 Sep 2019 04:04:15 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 39C49160231; Sat, 14 Sep 2019 01:04:09 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CnoQ2pgqHyB4; Sat, 14 Sep 2019 01:04:08 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 573AF160235; Sat, 14 Sep 2019 01:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xQP9hiIFL8Vt; Sat, 14 Sep 2019 01:04:08 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 31125160231; Sat, 14 Sep 2019 01:04:08 -0700 (PDT) In-Reply-To: <87woeidd4g.fsf@web.de> Content-Language: en-US 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:166428 Archived-At: This is a multi-part message in MIME format. --------------D4D810EA17EDE6283E48FC8C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/8/19 8:25 AM, Michael Heerdegen wrote: > 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? 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). 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.) Proposed ELPA fix attached; it should help performance in Emacs master (where I checked in some changes recently to help master work a bit better on this example). The abovementioned line shouldn't be needed in Emacs master. 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. --------------D4D810EA17EDE6283E48FC8C Content-Type: text/x-patch; name="0001-Port-GC-tuning-to-Emacs-27-alpha.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Port-GC-tuning-to-Emacs-27-alpha.patch" >From 3e85fb302a9cf88ed3668d41c4b2e4cdb7017c54 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 14 Sep 2019 01:01:20 -0700 Subject: [PATCH] Port GC tuning to Emacs 27 alpha * packages/el-search/el-search.el (el-search-setup-search): Set gc-cons-percentage to 0.8 while searching. --- packages/el-search/el-search.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/packages/el-search/el-search.el b/packages/el-search/el-search.el index 4e9cd98a4..5e213cf2b 100644 --- a/packages/el-search/el-search.el +++ b/packages/el-search/el-search.el @@ -2168,11 +2168,12 @@ files (i.e. file names) to search in. With optional FROM-HERE non-nil, the first buffer in this stream should be the current buffer, and searching will start at the current buffer's point instead of its beginning." + (let ((gc-cons-percentage 0.8)) (el-search-setup-search-1 pattern get-buffer-stream nil setup-function) (if (not el-search-occur-flag) (el-search-continue-search from-here) (setq el-search-occur-flag nil) - (el-search-occur))) + (el-search-occur)))) (defun el-search-stream-of-directory-files (&optional directory recurse) "Return a stream of emacs-lisp files in DIRECTORY. -- 2.21.0 --------------D4D810EA17EDE6283E48FC8C--