From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mitchell Newsgroups: gmane.emacs.bugs Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ Date: Thu, 20 Jun 2024 12:57:58 -0600 Message-ID: References: <86ed8tozub.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e0179f061b56e6b6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1375"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71644@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 20 23:43:14 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 1sKPYn-00009I-LG for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Jun 2024 23:43:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKPYb-00049m-Md; Thu, 20 Jun 2024 17:43: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 1sKPYa-00049X-HF for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 17:43:00 -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 1sKPYY-0002fj-Tr for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 17:42:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sKPYc-0000SF-VC for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 17:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mitchell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jun 2024 21:43: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.17189197411644 (code B ref 71644); Thu, 20 Jun 2024 21:43:02 +0000 Original-Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 21:42:21 +0000 Original-Received: from localhost ([127.0.0.1]:45201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKPXw-0000QQ-Iz for submit@debbugs.gnu.org; Thu, 20 Jun 2024 17:42:21 -0400 Original-Received: from mail-ed1-f42.google.com ([209.85.208.42]:46511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKN0a-0006LC-Ux for 71644@debbugs.gnu.org; Thu, 20 Jun 2024 14:59:46 -0400 Original-Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-57d10354955so1313901a12.1 for <71644@debbugs.gnu.org>; Thu, 20 Jun 2024 11:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718909915; x=1719514715; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Da/CLkPeVYhCzrNyBouO93PtWeh7bdHs+WlcagmYcxg=; b=gpYizBQqPzKkEvsCBRo2wm3ubm57CJWEwP7OSqr9fMilker4qBQyjBm6OBYxP15sUI nLjAqK9d1PzSbFYJk3fFTt0giHgw/L/+P7c0ffP4jo5KX4BE/1akpHgiNXYDg4+syGBx zXc4Tg15bVpz2juxTQCvkwnJJfXRt5gN1/SMuBYk1tFz2zzSVZeQByjdP2Sr6LkNDsHv nz+z8yh1eOMyuwcgKODn/YTD2UG30HB8GyZHNfS5du0+gPQDnAPRZWWC1n3IbcRfG7tD YJ7oSL+p8FLOkkFVgr3wlPdnnTXaOORdAXfVFw1EygDicbWfgFAKNw1V/eqOR01RmzAt gfuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718909915; x=1719514715; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Da/CLkPeVYhCzrNyBouO93PtWeh7bdHs+WlcagmYcxg=; b=I5uJMjTRfw4vDHz0U/FFpzUG6YaBMKQewpxujkdM+FNeU8gZ4R5HhFa01C0t1MFdP/ OgBFhue++8Enz/PXpVJ+VLSVqn05qJupvi6+WQTEMvnKHqjqkzYrlP5i5bYtuEU1r8tr OmWzcfqh2GXVIXq6SSgQIozBYSGbsJedTvi2KwT2b0Lnp67gPqC0WkJYwvBd6wXerAtn pOObvNS5PuZQ8f6dGG0MRP/kwNrIahoIx/mMv2wNi1BXzyrX6xcyMwgY01AtoSNo9Loz YX3kkBLUdpvqbv/ugG1Rkz9j48roPaudYvV9kljPTjaUqxTl/7l9BgLyyKFPV2rohU8g er1g== X-Gm-Message-State: AOJu0YxgllkX/ik80vnz71oUHQbS+Za25gDRC1U2kYrR0XJmrL2BXo+Q n7/L4uAq8Cfj1QAIWzys3rQ65HjP8zMMSHjoigVw617NL2VOCbS6ArSVdxcxbBHFUZ4NJQI27Rp l8k2vVh6iulwD2JST/EOKj06Ofs93qA7y X-Google-Smtp-Source: AGHT+IE0J+BKB/ag1djCEOe9NNGMiEmeMYVFHI1S4h7aw4na0AY5RfRNwNhKuq6I+6lo6elSLTDeaP+db5vQ2+xOGw4= X-Received: by 2002:a50:d713:0:b0:57c:68fd:2bc9 with SMTP id 4fb4d7f45d1cf-57d07e6bbf0mr3547964a12.3.1718909914844; Thu, 20 Jun 2024 11:58:34 -0700 (PDT) In-Reply-To: <86ed8tozub.fsf@gnu.org> X-Mailman-Approved-At: Thu, 20 Jun 2024 17:42:19 -0400 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:287600 Archived-At: --000000000000e0179f061b56e6b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the response, Eli. > Maybe the reason is that Emacs 30 now > uses Org 9.7.4, whereas you have a local installation of 9.6.30? Upgrading to Org 9.7.4 and reinstalling counsel did seem to improve the abbrev expansion speed slightly on my Emacs 30.0.50 build, at least at first. It=E2=80=99s still not nearly as snappy as 28.2 the longer I edit th= e buffer. I will work on a reliable recipe to recreate this slowness. > 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). I thought it was markers because (1) overwriting a few functions in counsel.el to be the versions at https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba7260 so that counsel-outline cleaned up the markers it created caused the bug to go away, and (2) the bug also exists when instead of counsel-outline at Step 5 I used org-refile (with `org-refile-use-cache` is set to `t`), and `org-refile-use-cache` seems to create many markers in the buffer. But maybe counsel-outline and org-refile are both doing something else that cause the bug. (FWIW I did also notice that the abbrev expansions were slightly quicker in Step 7 after using org-refile than after counsel-outline...) > 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. Abbrev expansions on my machine take longer. When I re-create the bug with counsel-outline, the abbrevs take over a second each to expand. Maybe your hardware is faster than mine? > I see 3400 markers created by counsel-outline in this case, which is > not too many, IMO. Interesting, maybe it isn=E2=80=99t markers after all. Can I ask how you co= unt markers? I couldn=E2=80=99t find anything in the docs or online. On Wed, Jun 19, 2024 at 6:57=E2=80=AFAM Eli Zaretskii wrote: > > 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 th= e > 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=E2=80=99t get a b= ig 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 th= e > 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. > --000000000000e0179f061b56e6b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the response, Eli.

<= /div>
> Maybe the reason is that Emacs 30 now
> uses Org 9.7.4= , whereas you have a local installation of 9.6.30?

Upgrading to Org 9.7.4 and reinstalling counsel did seem to improve t= he abbrev expansion speed slightly on my Emacs 30.0.50 build, at least at f= irst. It=E2=80=99s still not nearly as snappy as 28.2 the longer I edit the= buffer. I will work on a reliable recipe to recreate this slowness.

>=20 =20 Why did you decide the problem was due to markers?=C2=A0 I see a single
>=20 =20 change in the implementation of markers in Emacs 29 as compared to
>=20 =20 Emacs 28, and no changes at all in Emacs 30 (except one that affects
>=20 =20 the Android, I think).

I thought it was marke= rs because (1) overwriting a few functions in counsel.el to be the versions= at https://gist.github.com/kings2u/5a8acbf0986f0848be6= 6169d2dba7260 so that counsel-outline cleaned up the markers it created= caused the bug to go away, and (2) the bug also exists when=20 instead of counsel-outline=20 at Step 5 I used org-refile (with=20 `org-refile-use-cache` is set to `t`), and `org-refile-use-cache` seems to = create many markers in the buffer. But maybe counsel-outline and org-refile= are both doing something else that cause the bug. (FWIW I did also notice = that the abbrev expansions were slightly quicker in Step 7 after using org-= refile than after counsel-outline...)

>=20 I _can_ reproduce this in Emacs 29.3, where indeed
>=20 expanding any of the two abbrevs takes about 0.5 sec to show on the
>=20 screen.=C2=A0

Abbrev expansions on my machine= take longer. When I re-create the bug with counsel-outline, the abbrevs ta= ke over a second each to expand. Maybe your hardware is faster than mine?

>=20 =20 I see 3400 markers created by counsel-outline in this case, which is
>=20 =20 not too many, IMO.

Interesting, maybe it isn= =E2=80=99t markers after all. Can I ask how you count markers? I couldn=E2= =80=99t find anything in the docs or online.

On Wed, Jun 19, 2024= at 6:57=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Mitchell <mitchellahren@gmail.com>
> 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 issu= e, but it seems to be caused by the many
> markers that `counsel-outline` creates in the buffer. After invoking t= he 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 functi= ons that create a lot of markers in the
> buffer, like `org-refile` if `org-refile-use-cache` is set to `t`. I t= ried upgrading my system to emacs 30.0.50,
> which I've used to generate this bug report, but the issue persist= s.

I cannot reproduce this on my system, with the current master branch,
i.e. Emacs 30.=C2=A0 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.=C2=A0 But in Emacs 30 it's instantaneous, even though I used an=
unoptimized build of Emacs 30.=C2=A0 Maybe the reason is that Emacs 30 now<= br> 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?=C2=A0 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 funct= ion)` in the `profiler-report`. Using the
> `profiler` at the same points using emacs 28.2, I don=E2=80=99t 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 t= he
> 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).<= br> > 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 t= he headline at line 34.
> 6. Go to the end of the line and press `enter` to start typing on a ne= w line at line 35.
> 7. Start typing `n` `space`, or `t` `space` several times very fast an= d observe how long it takes for the abbrev
> expansions (defined in the minimal config above) to show up on the scr= een.

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:

=C2=A0 (add-to-list 'load-path "~/foo/ivy-0.14.2")
=C2=A0 (add-to-list 'load-path "~/foo/swiper-0.14.2")
=C2=A0 (setq-default abbrev-mode t)
=C2=A0 (setq save-abbrevs nil)
=C2=A0 (add-hook 'minibuffer-setup-hook (lambda () (setq-local abbrev-m= ode nil)))
=C2=A0 (define-abbrev global-abbrev-table "n" "and") =C2=A0 (define-abbrev global-abbrev-table "t" "the") =C2=A0 (define-abbrev global-abbrev-table "th" "that")<= br>
=C2=A0 M-x load-file RET ~/foo/counsel-0.14.2/counsel.el RET
=C2=A0 M-x eval-region RET

Then I did all the rest of steps.=C2=A0 As mentioned, I do see the slow
responses in Emacs 29.3, but not in the latest master branch of the
Emacs Git repository.
--000000000000e0179f061b56e6b6--