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#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ Date: Wed, 19 Jun 2024 15:56:44 +0300 Message-ID: <86ed8tozub.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6749"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71644@debbugs.gnu.org To: Mitchell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 19 14:58:25 2024 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 1sJutN-0001Ui-1h for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Jun 2024 14:58:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJusz-0006o4-AM; Wed, 19 Jun 2024 08:58:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJusx-0006ls-Uu for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 08:57:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sJusx-0001cf-Mk for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 08:57:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJut0-0007YK-Hc for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 08:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Jun 2024 12:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71644 X-GNU-PR-Package: emacs Original-Received: via spool by 71644-submit@debbugs.gnu.org id=B71644.171880184128954 (code B ref 71644); Wed, 19 Jun 2024 12:58:02 +0000 Original-Received: (at 71644) by debbugs.gnu.org; 19 Jun 2024 12:57:21 +0000 Original-Received: from localhost ([127.0.0.1]:42866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJusL-0007Wu-36 for submit@debbugs.gnu.org; Wed, 19 Jun 2024 08:57:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJusI-0007Wc-6L for 71644@debbugs.gnu.org; Wed, 19 Jun 2024 08:57:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJus9-0001VB-He; Wed, 19 Jun 2024 08:57:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=akuBMyuPWXy9JeGAhpzra7Ga6i2Xe0kCtEXbirHogU8=; b=M2ep+/YhEreJTBcBmUqp jok53vbOvODpXf4ZKax01LuxdEIk+XmlAcgy7qgIBSG89Gpi5RHbFyGGCWpExedy6+K96H6m83Hzp u2qTIIVPeNtrmLKV1KMwFpYaahmUHOrixwWWGCRV4gpARfKrQFVeEnKMZQ40SHlWrCGAww80DidIZ ZHOAPPJ7cmpzex2hBy5MwMaUrgNlOhh5/j7i1D/DcLCJfuPsTAbqQp7w0mJkHQqHgxPCYsFenuv3D zSolPpNWRlrCLN2gNGG0b8PbKuNE1811/n5MF+bGX3zE++C7Vr/SiZ+8qxaPHllzv8oUIIX1AK4Lz F67/PQmiDyfmfQ==; In-Reply-To: (message from Mitchell on Tue, 18 Jun 2024 23:25:18 -0600) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287481 Archived-At: > From: Mitchell > Date: Tue, 18 Jun 2024 23:25:18 -0600 > > I recently upgraded from emacs 28.2 to 29.3. When I resumed working in a large 11MB org-mode file that > never gave me problems with speed on 28.2, I noticed a severe slowdown when editing the buffer after > invoking `counsel-outline`. It took a while for me to isolate the issue, but it seems to be caused by the many > markers that `counsel-outline` creates in the buffer. After invoking the command, every subsequent edit to the > buffer renders much slower on screen than it did in 28.2. > > This problem is not only caused by `counsel-outline`, but other functions that create a lot of markers in the > buffer, like `org-refile` if `org-refile-use-cache` is set to `t`. I tried upgrading my system to emacs 30.0.50, > which I've used to generate this bug report, but the issue persists. I cannot reproduce this on my system, with the current master branch, i.e. Emacs 30. I _can_ reproduce this in Emacs 29.3, where indeed expanding any of the two abbrevs takes about 0.5 sec to show on the screen. But in Emacs 30 it's instantaneous, even though I used an unoptimized build of Emacs 30. Maybe the reason is that Emacs 30 now uses Org 9.7.4, whereas you have a local installation of 9.6.30? Why did you decide the problem was due to markers? I see a single change in the implementation of markers in Emacs 29 as compared to Emacs 28, and no changes at all in Emacs 30 (except one that affects the Android, I think). > Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and 5, and then `profiler-stop` after Step > 7, I get a very big entry (e.g., 70%) for `redisplay_internal (C function)` in the `profiler-report`. Using the > `profiler` at the same points using emacs 28.2, I don’t get a big entry for `redisplay_internal (C function)`. This doesn't necessarily mean the problem is due to the markers (but doesn't refute that, either). I see 3400 markers created by counsel-outline in this case, which is not too many, IMO. > Here are the steps to reproduce the issue: > > 1. Start emacs 29.3 (or 30.0.50) with emacs -q. > 2. Paste the minimal config at https://gist.github.com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de into the > scratch buffer and eval-buffer. (Note on my system I'm using the `counsel` version current as of > counsel-20240502.743, but any recent version will reproduce the bug). > 3. Open the following big file in org-mode: > https://gist.github.com/kings2u/c123a30de7e507a153a9500f03f08a9e > 4. `goto-line` 35. > 5. `M-x counsel-outline` and simply press enter to navigate point to the headline at line 34. > 6. Go to the end of the line and press `enter` to start typing on a new line at line 35. > 7. Start typing `n` `space`, or `t` `space` several times very fast and observe how long it takes for the abbrev > expansions (defined in the minimal config above) to show up on the screen. I didn't want to install all those packages (counsel is just the tip of the iceberg, it wants you to install ivy and swiper and whatnot), so I simply unpacked their tarballs from ELPA, and did this instead of steps 1 and 2 above: (add-to-list 'load-path "~/foo/ivy-0.14.2") (add-to-list 'load-path "~/foo/swiper-0.14.2") (setq-default abbrev-mode t) (setq save-abbrevs nil) (add-hook 'minibuffer-setup-hook (lambda () (setq-local abbrev-mode nil))) (define-abbrev global-abbrev-table "n" "and") (define-abbrev global-abbrev-table "t" "the") (define-abbrev global-abbrev-table "th" "that") M-x load-file RET ~/foo/counsel-0.14.2/counsel.el RET M-x eval-region RET Then I did all the rest of steps. As mentioned, I do see the slow responses in Emacs 29.3, but not in the latest master branch of the Emacs Git repository.