GNU bug report logs - #71644
30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mitchell <mitchellahren <at> gmail.com>
Cc: 71644 <at> debbugs.gnu.org
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Date: Thu, 20 Jun 2024 22:04:33 +0300

> From: Mitchell <mitchellahren <at> gmail.com>
> Date: Thu, 20 Jun 2024 12:57:58 -0600
> Cc: 71644 <at> 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 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...)

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’t markers after all. Can I ask how you count markers? I couldn’t 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=1.  So I compiled it and
called it from GDB.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.