> From: Mitchell <mitchellahren@gmail.com>
> 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 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.