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 20:46:51 -0600 Message-ID: References: <86ed8tozub.fsf@gnu.org> <86jzijmo5a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bf7750061b5d73dc" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12314"; 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 Fri Jun 21 04:49:17 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 1sKUKx-00030Z-Cg for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Jun 2024 04:49:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKUKg-0006cB-MQ; Thu, 20 Jun 2024 22:48:58 -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 1sKUKg-0006bv-4b for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 22:48:58 -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 1sKUKf-0001id-Sb for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 22:48:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sKUKj-0004gp-Tn for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 22:49:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mitchell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jun 2024 02:49:01 +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.171893812117993 (code B ref 71644); Fri, 21 Jun 2024 02:49:01 +0000 Original-Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 02:48:41 +0000 Original-Received: from localhost ([127.0.0.1]:53188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKUKO-0004g5-QE for submit@debbugs.gnu.org; Thu, 20 Jun 2024 22:48:41 -0400 Original-Received: from mail-lj1-f170.google.com ([209.85.208.170]:47521) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKUKM-0004fr-OB for 71644@debbugs.gnu.org; Thu, 20 Jun 2024 22:48:39 -0400 Original-Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2eaafda3b5cso17077531fa.3 for <71644@debbugs.gnu.org>; Thu, 20 Jun 2024 19:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718938048; x=1719542848; 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=yhS2iew0iFU2Ggl9J3XfnvRg2RLQCK/Ezv2hMCM4SG8=; b=IO+x3a6ZGyeXRPFhFhlSUMb6UQRenYU4PvXPchdD4l96Q8MStyZyF4H/1tsDp+ZEaK BTN0RTHQhkN/ZL5HtSe4iqC+SpzuQWcMiQ/dYEmsoDLcY6yo7GPKReyuiC5/fgwuOjzH Dg8t5fBgXUEuejrMFyyjPuX5eWnvVuirnx1f/2p91QCZIChExwExDGpTLQ3CASlp17/8 p5mq8mMYoWx2emiq0DXbSE+BpiXuBa01eQ1WZcLWJshhOCUVvpETL+9ihbLKeNPXSIvR LMyAiWtOl6xJcuuHjukLuL1otEXdMEHhpj/ZGkJ8jjiCl11cqCDOUJz76+XMQPdLslKD 3ABA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718938048; x=1719542848; 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=yhS2iew0iFU2Ggl9J3XfnvRg2RLQCK/Ezv2hMCM4SG8=; b=wIOI21KWKZXZ+q01Lo82KH7GZ5GYzQhXJ5glYsXqn3qxfiXoEuveyWzeQrFZiSoPX0 HVv2GnCu2r/yq4GqTm94gqqZrZseLyvEAbiEat3TE9/gJCnZXcCxDA42Oeei5nMiz5QW uqJHxBVsIS/e511W1CJBtAcGpAeY/2jEoUw3cXLMYHnHQ7ZKtHduXNQRHK73oWU4w1Wr wTfjkaFMQPwXMRj3m6lTGhQ9U89Ubj06DuaFrFWmkXG+sE0iviTPvUwq1uKkZwMlqw32 RMRg4lFVok0HTVySU5fp5O4AipG9Ua2ifoJHZMoKRHGAb+mXwlsOhrDAmTgGxcEX+1WE DShg== X-Gm-Message-State: AOJu0YxyXnOokd7qswqEOS4VbGJOy0/4xITy1ifUYo6H4Ev9ew7ohYEa Bg5t9PEnJHRKgsSVEoElhy4ckS9apg4/RlElH4WK9eVm4SBscnZ1ZroRfL+0iy9swKHCQ+pjoEs ZotAVUTl57aqbkh23luL6kFt4uYpUVeXwaVc= X-Google-Smtp-Source: AGHT+IH3S5hslLsffp1mzqy6B8jmcCSlEg6pRmQdK+QRnS1FrcpuA3d1KauPm6q4DRoncstidgt/kQjfn6fl1+S3jsU= X-Received: by 2002:a2e:9e4d:0:b0:2ec:1ce8:9a7d with SMTP id 38308e7fff4ca-2ec3ce974bdmr43543891fa.4.1718938048098; Thu, 20 Jun 2024 19:47:28 -0700 (PDT) In-Reply-To: <86jzijmo5a.fsf@gnu.org> 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:287608 Archived-At: --000000000000bf7750061b5d73dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > If you remove all the non-ASCII characters from the Org file, does the > slowdown go away? Eli, that solved it! The new test file is at https://gist.github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2. I replaced every non-ASCII character with an "a" so the file still has the same number of total characters, and in my emacs 30.0 50 build (as of 2024-05-25), doing Steps 1 to Step 7 gives me abbrev expansions that are as lighting fast as in emacs 28.2! So what now? Do you think you can solve what=E2=80=99s going on in the back= end so bigger buffers with markers and non-ASCII characters don=E2=80=99t exhibit = this slowness in the latest emacs? Thank you again! On Thu, Jun 20, 2024 at 1:04=E2=80=AFPM Eli Zaretskii wrote: > > From: Mitchell > > Date: Thu, 20 Jun 2024 12:57:58 -0600 > > Cc: 71644@debbugs.gnu.org > > > > > 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 ar= e > 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...) > > If you remove all the non-ASCII characters from the Org file, does the > slowdown go away? > > > > 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? > > Could be, but twice slower sounds too much to be explained by CPU > speed. > > > > 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 yo= u count > markers? I couldn=E2=80=99t find anything in the > > docs or online. > > There's a function count_markers in Emacs, it just isn't compiled > unless you compile with -DDEBUG_MARKERS=3D1. So I compiled it and > called it from GDB. > --000000000000bf7750061b5d73dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> If you remov= e all the non-ASCII characters from the Org file, does the
>=20 slowdown go away?
=
Eli, that solved it! The new test file is at https://gist.= github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2. I replaced every non-ASCII character with an "a" so the file still has the same nu= mber of total characters, and in my emacs 30.0 50 build (as of 2024-05-25),= doing Steps 1 to Step 7 gives me abbrev expansions that are as lighting fa= st as in emacs 28.2!

So = what now? Do you think you can solve what=E2=80=99s going on in the backend= so bigger buffers with markers and non-ASCII characters=20 don=E2=80=99t exhibit this slowness in the latest emacs?

Thank you again!

On Thu, Jun 20, 2024 at 1:04=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Mitchell <mitchellahren@gmail.com>
> Date: Thu, 20 Jun 2024 12:57:58 -0600
> Cc: 71644@d= ebbugs.gnu.org
>
> > 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 t= o
> > Emacs 28, and no changes at all in Emacs 30 (except one that affe= cts
> > the Android, I think).
>
> I thought it was markers because (1) overwriting a few functions in co= unsel.el to be the versions at
> https://gist.github.com/kings2u= /5a8acbf0986f0848be66169d2dba7260 so that counsel-outline cleaned up th= e
> markers it created caused the bug to go away, and (2) the bug also exi= sts 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 a= re 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...)

If you remove all the non-ASCII characters from the Org file, does the
slowdown go away?

> > I _can_ reproduce this in Emacs 29.3, where indeed
> > expanding any of the two abbrevs takes about 0.5 sec to show on t= he
> > screen.=C2=A0
>
> 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?

Could be, but twice slower sounds too much to be explained by CPU
speed.

> > 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 y= ou count markers? I couldn=E2=80=99t find anything in the
> docs or online.

There's a function count_markers in Emacs, it just isn't compiled unless you compile with -DDEBUG_MARKERS=3D1.=C2=A0 So I compiled it and
called it from GDB.
--000000000000bf7750061b5d73dc--