GNU logs - #71644, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Mitchell <mitchellahren@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jun 2024 08:03:02 +0000
Resent-Message-ID: <handler.71644.B.171878417716213 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 71644 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Mitchell <mitchellahren@HIDDEN>
Date: Tue, 18 Jun 2024 23:25:18 -0600
Message-ID: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000b4d60d061b376e60"
Received-SPF: pass client-ip=2a00:1450:4864:20::536;
 envelope-from=mitchellahren@HIDDEN; helo=mail-ed1-x536.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Mailman-Approved-At: Wed, 19 Jun 2024 04:02:52 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--000000000000b4d60d061b376e60
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

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.

To verify this slowdown doesn=E2=80=99t occur before invoking `counsel-outl=
ine`,
when all the markers in the buffer were created, you can try the steps
again beginning from Step 1 but after Step 4, jump to Step 7 and see how
fast the abbrevs expand. You can also repeat all Steps 1 through 7 above
with emacs -q using emacs 28.2 and see that no slowdown occurs at Step 7.

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 big e=
ntry for
`redisplay_internal (C function)`.

This slowdown during editing only seems noticeable with larger files, but
they don=E2=80=99t have to be 11MB like the first test file. I still notice=
 a
half-second difference at least between emacs 29+ and emacs 28.2 when in
Step 3 I instead use the 5MB file at
https://gist.github.com/kings2u/7f607bd1069fbe92d611de70b39b936c. It wasn=
=E2=80=99t
until I reduced the test file to about 2.5MB that I saw emacs 29+
performing edits at the same speed as emacs 28.2 in Step 7 (see this
smallest file at:
https://gist.github.com/kings2u/2f76d30cea4f12c1bb90fe4f3a90e36e).

I=E2=80=99ve tried many different setups to avoid the problem, including di=
fferent
versions of org-mode, but the only thing that solves it is going back to
emacs 28.2, which apparently handles markers more efficiently than 29+. The
only way to solve the problem while staying in emacs 29.3 that I=E2=80=99ve=
 found
is to modify `counsel-outline` to not generate markers. (This solution was
suggested at https://github.com/abo-abo/swiper/pull/1700. The specific
modifications I use can be found at
https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba7260). For what
it=E2=80=99s worth, I have installed emacs 29.3+ on multiple different mach=
ines and
observed the exact same behavior.

My big 11MB org file is such an integral part of my workflow that I've gone
back to emacs 28.2 for now with the hopes that the current version of emacs
will go back to handling markers efficiently. Please let me know if I can
help further in diagnosing the problem.

Thank you for all you do!


In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-05-25 built
 on MITCHELL-16G-TO
Repository revision: 57dc1ed665d72bc58befa4853fa479b770fe4fcc
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Home (v10.0.2009.19045.4412)

Configured using:
 'configure --prefix=3D/c/emacs --with-modules --without-dbus
 --with-native-compilation --without-compress-install --with-tree-sitter
 --with-mailutils --without-gconf --without-gsettings 'CFLAGS=3D-O2
 -mtune=3Dnative -march=3Dnative -fomit-frame-pointer''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  global-tab-line-mode: t
  tab-line-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
c:/Users/Mitchell/Emacs/.emacs.d/elpa/transient-20240509.1849/transient
hides c:/emacs/share/emacs/30.0.50/lisp/transient
c:/Users/Mitchell/Emacs/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides
c:/emacs/share/emacs/30.0.50/lisp/bind-key
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package=
-lint
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-lint
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package=
-jump
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-jump
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package=
-ensure
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-ensure
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package=
-diminish
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-diminish
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package=
-delight
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-delight
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package=
-core
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-core
c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package=
-bind-key
hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-bind-key
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-texinfo hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-texinfo
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-publish hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-publish
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-org hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-org
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-odt hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-odt
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-md hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-md
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-man hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-man
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-latex hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-latex
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-koma-letter hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-koma-letter
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-icalendar hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-icalendar
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-html hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-html
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-beamer hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-beamer
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-ascii hides
c:/emacs/share/emacs/30.0.50/lisp/org/ox-ascii
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org hides
c:/emacs/share/emacs/30.0.50/lisp/org/org
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-version hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-version
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-timer hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-timer
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-tempo hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-tempo
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-table hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-table
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-src hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-src
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-refile hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-refile
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-protocol hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-protocol
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-plot hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-plot
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-persist hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-persist
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-pcomplete hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-pcomplete
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-num hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-num
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-mouse hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-mouse
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-mobile hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-mobile
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-macs hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-macs
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-macro hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-macro
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-loaddefs hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-loaddefs
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-list hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-list
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-lint hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-lint
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-keys hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-keys
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-inlinetask hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-inlinetask
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-indent hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-indent
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-id hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-id
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-habit hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-habit
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-goto hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-goto
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-footnote hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-footnote
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-fold hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-fold
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-fold-core hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-fold-core
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-feed hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-feed
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-faces hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-faces
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-entities hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-entities
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-element hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-element
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-duration hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-duration
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-datetree hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-datetree
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-cycle hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-cycle
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-ctags hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-ctags
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-crypt hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-crypt
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-compat hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-compat
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-colview hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-colview
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-clock hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-clock
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-capture hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-capture
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-attach hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-attach
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-attach-git hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-attach-git
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-archive hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-archive
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-agenda hides
c:/emacs/share/emacs/30.0.50/lisp/org/org-agenda
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-w3m hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-w3m
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-rmail hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-rmail
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-mhe hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-mhe
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-man hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-man
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-irc hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-irc
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-info hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-info
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-gnus hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-gnus
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-eww hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-eww
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-eshell hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-eshell
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-doi hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-doi
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-docview hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-docview
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-bibtex hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-bibtex
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-bbdb hides
c:/emacs/share/emacs/30.0.50/lisp/org/ol-bbdb
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc hides
c:/emacs/share/emacs/30.0.50/lisp/org/oc
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-natbib hides
c:/emacs/share/emacs/30.0.50/lisp/org/oc-natbib
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-csl hides
c:/emacs/share/emacs/30.0.50/lisp/org/oc-csl
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-bibtex hides
c:/emacs/share/emacs/30.0.50/lisp/org/oc-bibtex
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-biblatex hides
c:/emacs/share/emacs/30.0.50/lisp/org/oc-biblatex
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-basic hides
c:/emacs/share/emacs/30.0.50/lisp/org/oc-basic
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-tangle hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-tangle
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-table hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-table
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sqlite hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-sqlite
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sql hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-sql
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-shell hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-shell
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sed hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-sed
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-screen hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-screen
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-scheme hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-scheme
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sass hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-sass
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ruby hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-ruby
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ref hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-ref
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-R hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-R
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-python hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-python
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-processing hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-processing
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-plantuml hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-plantuml
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-perl hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-perl
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-org hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-org
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-octave hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-octave
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ocaml hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-ocaml
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-maxima hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-maxima
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-matlab hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-matlab
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-makefile hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-makefile
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lua hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-lua
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lob hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-lob
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lisp hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-lisp
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lilypond hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-lilypond
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-latex hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-latex
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-julia hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-julia
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-js hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-js
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-java hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-java
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-haskell hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-haskell
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-groovy hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-groovy
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-gnuplot hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-gnuplot
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-fortran hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-fortran
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-forth hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-forth
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-exp hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-exp
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-eval hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-eval
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-eshell hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-eshell
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-emacs-lisp hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-emacs-lisp
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-dot hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-dot
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ditaa hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-ditaa
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-css hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-css
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-core hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-core
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-comint hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-comint
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-clojure hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-clojure
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-calc hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-calc
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-C hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-C
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-awk hides
c:/emacs/share/emacs/30.0.50/lisp/org/ob-awk

Features:
(shadow sort mail-extr emacsbug message yank-media puny rfc822 mml
mml-sec epa derived gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete
org-list org-footnote org-faces org-entities time-date noutline outline
ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx org-fold
org-fold-core org-keys oc org-loaddefs find-func cal-menu calendar
cal-loaddefs org-version org-compat org-macs format-spec counsel xdg
xref project dired dired-loaddefs compile text-property-search comint
ansi-osc ansi-color swiper ivy delsel ring ivy-faces ivy-overlay colir
color modus-vivendi-theme modus-themes cl-extra help-mode tab-line
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core finder-inf easy-mmode epg
rfc6068 epg-config gnu-elpa-keyring-update pdf-tools-autoloads
tablist-autoloads info package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv
bytecomp byte-compile url-vars cus-edit pp cus-start cus-load icons
wid-edit cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 476739 29195) (symbols 48 26493 0)
 (strings 32 133104 6737) (string-bytes 1 3784773) (vectors 16 33874)
 (vector-slots 8 430476 21000) (floats 8 269 15) (intervals 56 554 0)
 (buffers 992 12))

--000000000000b4d60d061b376e60
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I recently upgraded from emacs 28.2 to 29.3. When I resume=
d working in a large 11MB org-mode file that never gave me problems with sp=
eed on 28.2, I noticed a severe slowdown when editing the buffer after invo=
king `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 t=
he buffer. After invoking the command, every subsequent edit to the buffer =
renders much slower on screen than it did in 28.2.<br><br>This problem is n=
ot 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 se=
t to `t`. I tried upgrading my system to emacs 30.0.50, which I&#39;ve used=
 to generate this bug report, but the issue persists. <br><br>Here are the =
steps to reproduce the issue:<br><br>1. Start emacs 29.3 (or 30.0.50) with =
emacs -q.<br>2. Paste the minimal config at <a href=3D"https://gist.github.=
com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de">https://gist.github.com/kings=
2u/30b7a22dfa38fe0d5dc18adaf0e5e9de</a> into the scratch buffer and eval-bu=
ffer. (Note on my system I&#39;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: <a href=3D"https://gist.github.co=
m/kings2u/c123a30de7e507a153a9500f03f08a9e">https://gist.github.com/kings2u=
/c123a30de7e507a153a9500f03f08a9e</a><br>4. `goto-line` 35.<br>5. `M-x coun=
sel-outline` and simply press enter to navigate point to the headline at li=
ne 34.<br>6. Go to the end of the line and press `enter` to start typing on=
 a new line at line 35.<br>7. Start typing `n` `space`, or `t` `space` seve=
ral 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.<br><br>To =
verify this slowdown doesn=E2=80=99t occur before invoking `counsel-outline=
`, when all the markers in the buffer were created, you can try the steps a=
gain beginning from Step 1 but after Step 4, jump to Step 7 and see how fas=
t the abbrevs expand. You can also repeat all Steps 1 through 7 above with =
emacs -q using emacs 28.2 and see that no slowdown occurs at Step 7.<br><br=
>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%) f=
or `redisplay_internal (C function)` in the `profiler-report`. Using the `p=
rofiler` at the same points using emacs 28.2, I don=E2=80=99t get a big ent=
ry for `redisplay_internal (C function)`.<br><br><div>This slowdown during =
editing only seems noticeable with larger files, but they don=E2=80=99t hav=
e to be 11MB like the first test file. I still notice a half-second differe=
nce at least between emacs 29+ and emacs 28.2 when in Step 3 I instead use =
the 5MB file at <a href=3D"https://gist.github.com/kings2u/7f607bd1069fbe92=
d611de70b39b936c">https://gist.github.com/kings2u/7f607bd1069fbe92d611de70b=
39b936c</a>. It wasn=E2=80=99t until I reduced the test file to about 2.5MB=
 that I saw emacs 29+ performing edits at the same speed as emacs 28.2 in S=
tep 7 (see this smallest file at: <a href=3D"https://gist.github.com/kings2=
u/2f76d30cea4f12c1bb90fe4f3a90e36e">https://gist.github.com/kings2u/2f76d30=
cea4f12c1bb90fe4f3a90e36e</a>).</div><div><br></div><div>I=E2=80=99ve tried=
 many different setups to avoid the problem, including different versions o=
f org-mode, but the only thing that solves it is going back to emacs 28.2, =
which apparently handles markers more efficiently than 29+. The only way to=
 solve the problem while staying in emacs 29.3 that I=E2=80=99ve found is t=
o modify `counsel-outline` to not generate markers. (This solution was sugg=
ested at <a href=3D"https://github.com/abo-abo/swiper/pull/1700">https://gi=
thub.com/abo-abo/swiper/pull/1700</a>. The specific modifications I use can=
 be found at <a href=3D"https://gist.github.com/kings2u/5a8acbf0986f0848be6=
6169d2dba7260">https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba=
7260</a>). For what it=E2=80=99s worth, I have installed emacs 29.3+ on mul=
tiple different machines and observed the exact same behavior.<br></div><br=
>My big 11MB org file is such an integral part of my workflow that I&#39;ve=
 gone back to emacs 28.2 for now with the hopes that the current version of=
 emacs will go back to handling markers efficiently. Please let me know if =
I can help further in diagnosing the problem.<br><br>Thank you for all you =
do!<br><br><br>In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-0=
5-25 built<br>=C2=A0on MITCHELL-16G-TO<br>Repository revision: 57dc1ed665d7=
2bc58befa4853fa479b770fe4fcc<br>Repository branch: master<br>Windowing syst=
em distributor &#39;Microsoft Corp.&#39;, version 10.0.19045<br>System Desc=
ription: Microsoft Windows 10 Home (v10.0.2009.19045.4412)<br><br>Configure=
d using:<br>=C2=A0&#39;configure --prefix=3D/c/emacs --with-modules --witho=
ut-dbus<br>=C2=A0--with-native-compilation --without-compress-install --wit=
h-tree-sitter<br>=C2=A0--with-mailutils --without-gconf --without-gsettings=
 &#39;CFLAGS=3D-O2<br>=C2=A0-mtune=3Dnative -march=3Dnative -fomit-frame-po=
inter&#39;&#39;<br><br>Configured features:<br>ACL GIF GMP GNUTLS HARFBUZZ =
JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP<br>NOTIFY W32NOTIFY PDUMPER PNG RSVG=
 SOUND SQLITE3 THREADS TIFF<br>TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLI=
B<br><br>Important settings:<br>=C2=A0 value of $LANG: ENU<br>=C2=A0 locale=
-coding-system: cp1252<br><br>Major mode: Lisp Interaction<br><br>Minor mod=
es in effect:<br>=C2=A0 global-tab-line-mode: t<br>=C2=A0 tab-line-mode: t<=
br>=C2=A0 override-global-mode: t<br>=C2=A0 tooltip-mode: t<br>=C2=A0 globa=
l-eldoc-mode: t<br>=C2=A0 eldoc-mode: t<br>=C2=A0 show-paren-mode: t<br>=C2=
=A0 electric-indent-mode: t<br>=C2=A0 mouse-wheel-mode: t<br>=C2=A0 tool-ba=
r-mode: t<br>=C2=A0 menu-bar-mode: t<br>=C2=A0 file-name-shadow-mode: t<br>=
=C2=A0 global-font-lock-mode: t<br>=C2=A0 font-lock-mode: t<br>=C2=A0 blink=
-cursor-mode: t<br>=C2=A0 minibuffer-regexp-mode: t<br>=C2=A0 line-number-m=
ode: t<br>=C2=A0 indent-tabs-mode: t<br>=C2=A0 transient-mark-mode: t<br>=
=C2=A0 auto-composition-mode: t<br>=C2=A0 auto-encryption-mode: t<br>=C2=A0=
 auto-compression-mode: t<br>=C2=A0 abbrev-mode: t<br><br>Load-path shadows=
:<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/transient-20240509.1849/transien=
t hides c:/emacs/share/emacs/30.0.50/lisp/transient<br>c:/Users/Mitchell/Em=
acs/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides c:/emacs/share/emac=
s/30.0.50/lisp/bind-key<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-packag=
e-20230426.2324/use-package hides c:/emacs/share/emacs/30.0.50/lisp/use-pac=
kage/use-package<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230=
426.2324/use-package-lint hides c:/emacs/share/emacs/30.0.50/lisp/use-packa=
ge/use-package-lint<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20=
230426.2324/use-package-jump hides c:/emacs/share/emacs/30.0.50/lisp/use-pa=
ckage/use-package-jump<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package=
-20230426.2324/use-package-ensure hides c:/emacs/share/emacs/30.0.50/lisp/u=
se-package/use-package-ensure<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-=
package-20230426.2324/use-package-diminish hides c:/emacs/share/emacs/30.0.=
50/lisp/use-package/use-package-diminish<br>c:/Users/Mitchell/Emacs/.emacs.=
d/elpa/use-package-20230426.2324/use-package-delight hides c:/emacs/share/e=
macs/30.0.50/lisp/use-package/use-package-delight<br>c:/Users/Mitchell/Emac=
s/.emacs.d/elpa/use-package-20230426.2324/use-package-core hides c:/emacs/s=
hare/emacs/30.0.50/lisp/use-package/use-package-core<br>c:/Users/Mitchell/E=
macs/.emacs.d/elpa/use-package-20230426.2324/use-package-bind-key hides c:/=
emacs/share/emacs/30.0.50/lisp/use-package/use-package-bind-key<br>c:/Users=
/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox hides c:/emacs/share/emacs/30.0=
.50/lisp/org/ox<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-texi=
nfo hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-texinfo<br>c:/Users/Mitc=
hell/Emacs/.emacs.d/elpa/org-9.6.30/ox-publish hides c:/emacs/share/emacs/3=
0.0.50/lisp/org/ox-publish<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6=
.30/ox-org hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-org<br>c:/Users/M=
itchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-odt hides c:/emacs/share/emacs/30=
.0.50/lisp/org/ox-odt<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/o=
x-md hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-md<br>c:/Users/Mitchell=
/Emacs/.emacs.d/elpa/org-9.6.30/ox-man hides c:/emacs/share/emacs/30.0.50/l=
isp/org/ox-man<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-latex=
 hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-latex<br>c:/Users/Mitchell/=
Emacs/.emacs.d/elpa/org-9.6.30/ox-koma-letter hides c:/emacs/share/emacs/30=
.0.50/lisp/org/ox-koma-letter<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-=
9.6.30/ox-icalendar hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-icalenda=
r<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-html hides c:/emac=
s/share/emacs/30.0.50/lisp/org/ox-html<br>c:/Users/Mitchell/Emacs/.emacs.d/=
elpa/org-9.6.30/ox-beamer hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-be=
amer<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-ascii hides c:/=
emacs/share/emacs/30.0.50/lisp/org/ox-ascii<br>c:/Users/Mitchell/Emacs/.ema=
cs.d/elpa/org-9.6.30/org hides c:/emacs/share/emacs/30.0.50/lisp/org/org<br=
>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-version hides c:/emac=
s/share/emacs/30.0.50/lisp/org/org-version<br>c:/Users/Mitchell/Emacs/.emac=
s.d/elpa/org-9.6.30/org-timer hides c:/emacs/share/emacs/30.0.50/lisp/org/o=
rg-timer<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-tempo hide=
s c:/emacs/share/emacs/30.0.50/lisp/org/org-tempo<br>c:/Users/Mitchell/Emac=
s/.emacs.d/elpa/org-9.6.30/org-table hides c:/emacs/share/emacs/30.0.50/lis=
p/org/org-table<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-src=
 hides c:/emacs/share/emacs/30.0.50/lisp/org/org-src<br>c:/Users/Mitchell/E=
macs/.emacs.d/elpa/org-9.6.30/org-refile hides c:/emacs/share/emacs/30.0.50=
/lisp/org/org-refile<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/or=
g-protocol hides c:/emacs/share/emacs/30.0.50/lisp/org/org-protocol<br>c:/U=
sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-plot hides c:/emacs/share/=
emacs/30.0.50/lisp/org/org-plot<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/or=
g-9.6.30/org-persist hides c:/emacs/share/emacs/30.0.50/lisp/org/org-persis=
t<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-pcomplete hides c=
:/emacs/share/emacs/30.0.50/lisp/org/org-pcomplete<br>c:/Users/Mitchell/Ema=
cs/.emacs.d/elpa/org-9.6.30/org-num hides c:/emacs/share/emacs/30.0.50/lisp=
/org/org-num<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-mouse =
hides c:/emacs/share/emacs/30.0.50/lisp/org/org-mouse<br>c:/Users/Mitchell/=
Emacs/.emacs.d/elpa/org-9.6.30/org-mobile hides c:/emacs/share/emacs/30.0.5=
0/lisp/org/org-mobile<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/o=
rg-macs hides c:/emacs/share/emacs/30.0.50/lisp/org/org-macs<br>c:/Users/Mi=
tchell/Emacs/.emacs.d/elpa/org-9.6.30/org-macro hides c:/emacs/share/emacs/=
30.0.50/lisp/org/org-macro<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6=
.30/org-loaddefs hides c:/emacs/share/emacs/30.0.50/lisp/org/org-loaddefs<b=
r>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-list hides c:/emacs/=
share/emacs/30.0.50/lisp/org/org-list<br>c:/Users/Mitchell/Emacs/.emacs.d/e=
lpa/org-9.6.30/org-lint hides c:/emacs/share/emacs/30.0.50/lisp/org/org-lin=
t<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-keys hides c:/ema=
cs/share/emacs/30.0.50/lisp/org/org-keys<br>c:/Users/Mitchell/Emacs/.emacs.=
d/elpa/org-9.6.30/org-inlinetask hides c:/emacs/share/emacs/30.0.50/lisp/or=
g/org-inlinetask<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-in=
dent hides c:/emacs/share/emacs/30.0.50/lisp/org/org-indent<br>c:/Users/Mit=
chell/Emacs/.emacs.d/elpa/org-9.6.30/org-id hides c:/emacs/share/emacs/30.0=
.50/lisp/org/org-id<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org=
-habit hides c:/emacs/share/emacs/30.0.50/lisp/org/org-habit<br>c:/Users/Mi=
tchell/Emacs/.emacs.d/elpa/org-9.6.30/org-goto hides c:/emacs/share/emacs/3=
0.0.50/lisp/org/org-goto<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.3=
0/org-footnote hides c:/emacs/share/emacs/30.0.50/lisp/org/org-footnote<br>=
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-fold hides c:/emacs/sh=
are/emacs/30.0.50/lisp/org/org-fold<br>c:/Users/Mitchell/Emacs/.emacs.d/elp=
a/org-9.6.30/org-fold-core hides c:/emacs/share/emacs/30.0.50/lisp/org/org-=
fold-core<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-feed hide=
s c:/emacs/share/emacs/30.0.50/lisp/org/org-feed<br>c:/Users/Mitchell/Emacs=
/.emacs.d/elpa/org-9.6.30/org-faces hides c:/emacs/share/emacs/30.0.50/lisp=
/org/org-faces<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-enti=
ties hides c:/emacs/share/emacs/30.0.50/lisp/org/org-entities<br>c:/Users/M=
itchell/Emacs/.emacs.d/elpa/org-9.6.30/org-element hides c:/emacs/share/ema=
cs/30.0.50/lisp/org/org-element<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/or=
g-9.6.30/org-duration hides c:/emacs/share/emacs/30.0.50/lisp/org/org-durat=
ion<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-datetree hides =
c:/emacs/share/emacs/30.0.50/lisp/org/org-datetree<br>c:/Users/Mitchell/Ema=
cs/.emacs.d/elpa/org-9.6.30/org-cycle hides c:/emacs/share/emacs/30.0.50/li=
sp/org/org-cycle<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-ct=
ags hides c:/emacs/share/emacs/30.0.50/lisp/org/org-ctags<br>c:/Users/Mitch=
ell/Emacs/.emacs.d/elpa/org-9.6.30/org-crypt hides c:/emacs/share/emacs/30.=
0.50/lisp/org/org-crypt<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30=
/org-compat hides c:/emacs/share/emacs/30.0.50/lisp/org/org-compat<br>c:/Us=
ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-colview hides c:/emacs/shar=
e/emacs/30.0.50/lisp/org/org-colview<br>c:/Users/Mitchell/Emacs/.emacs.d/el=
pa/org-9.6.30/org-clock hides c:/emacs/share/emacs/30.0.50/lisp/org/org-clo=
ck<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-capture hides c:=
/emacs/share/emacs/30.0.50/lisp/org/org-capture<br>c:/Users/Mitchell/Emacs/=
.emacs.d/elpa/org-9.6.30/org-attach hides c:/emacs/share/emacs/30.0.50/lisp=
/org/org-attach<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-att=
ach-git hides c:/emacs/share/emacs/30.0.50/lisp/org/org-attach-git<br>c:/Us=
ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-archive hides c:/emacs/shar=
e/emacs/30.0.50/lisp/org/org-archive<br>c:/Users/Mitchell/Emacs/.emacs.d/el=
pa/org-9.6.30/org-agenda hides c:/emacs/share/emacs/30.0.50/lisp/org/org-ag=
enda<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol hides c:/emacs/=
share/emacs/30.0.50/lisp/org/ol<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/or=
g-9.6.30/ol-w3m hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-w3m<br>c:/Us=
ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-rmail hides c:/emacs/share/e=
macs/30.0.50/lisp/org/ol-rmail<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org=
-9.6.30/ol-mhe hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-mhe<br>c:/Use=
rs/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-man hides c:/emacs/share/emac=
s/30.0.50/lisp/org/ol-man<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.=
30/ol-irc hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-irc<br>c:/Users/Mi=
tchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-info hides c:/emacs/share/emacs/30=
.0.50/lisp/org/ol-info<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/=
ol-gnus hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-gnus<br>c:/Users/Mit=
chell/Emacs/.emacs.d/elpa/org-9.6.30/ol-eww hides c:/emacs/share/emacs/30.0=
.50/lisp/org/ol-eww<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-=
eshell hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-eshell<br>c:/Users/Mi=
tchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-doi hides c:/emacs/share/emacs/30.=
0.50/lisp/org/ol-doi<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol=
-docview hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-docview<br>c:/Users=
/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-bibtex hides c:/emacs/share/ema=
cs/30.0.50/lisp/org/ol-bibtex<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-=
9.6.30/ol-bbdb hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-bbdb<br>c:/Us=
ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc hides c:/emacs/share/emacs/3=
0.0.50/lisp/org/oc<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-n=
atbib hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-natbib<br>c:/Users/Mit=
chell/Emacs/.emacs.d/elpa/org-9.6.30/oc-csl hides c:/emacs/share/emacs/30.0=
.50/lisp/org/oc-csl<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-=
bibtex hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-bibtex<br>c:/Users/Mi=
tchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-biblatex hides c:/emacs/share/emac=
s/30.0.50/lisp/org/oc-biblatex<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org=
-9.6.30/oc-basic hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-basic<br>c:=
/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob hides c:/emacs/share/emac=
s/30.0.50/lisp/org/ob<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/o=
b-tangle hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-tangle<br>c:/Users/=
Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-table hides c:/emacs/share/emacs=
/30.0.50/lisp/org/ob-table<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6=
.30/ob-sqlite hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sqlite<br>c:/U=
sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sql hides c:/emacs/share/em=
acs/30.0.50/lisp/org/ob-sql<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.=
6.30/ob-shell hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-shell<br>c:/Us=
ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sed hides c:/emacs/share/ema=
cs/30.0.50/lisp/org/ob-sed<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6=
.30/ob-screen hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-screen<br>c:/U=
sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-scheme hides c:/emacs/share=
/emacs/30.0.50/lisp/org/ob-scheme<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/=
org-9.6.30/ob-sass hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sass<br>c=
:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ruby hides c:/emacs/shar=
e/emacs/30.0.50/lisp/org/ob-ruby<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/o=
rg-9.6.30/ob-ref hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ref<br>c:/U=
sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-R hides c:/emacs/share/emac=
s/30.0.50/lisp/org/ob-R<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30=
/ob-python hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-python<br>c:/User=
s/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-processing hides c:/emacs/shar=
e/emacs/30.0.50/lisp/org/ob-processing<br>c:/Users/Mitchell/Emacs/.emacs.d/=
elpa/org-9.6.30/ob-plantuml hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-=
plantuml<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-perl hides =
c:/emacs/share/emacs/30.0.50/lisp/org/ob-perl<br>c:/Users/Mitchell/Emacs/.e=
macs.d/elpa/org-9.6.30/ob-org hides c:/emacs/share/emacs/30.0.50/lisp/org/o=
b-org<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-octave hides c=
:/emacs/share/emacs/30.0.50/lisp/org/ob-octave<br>c:/Users/Mitchell/Emacs/.=
emacs.d/elpa/org-9.6.30/ob-ocaml hides c:/emacs/share/emacs/30.0.50/lisp/or=
g/ob-ocaml<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-maxima hi=
des c:/emacs/share/emacs/30.0.50/lisp/org/ob-maxima<br>c:/Users/Mitchell/Em=
acs/.emacs.d/elpa/org-9.6.30/ob-matlab hides c:/emacs/share/emacs/30.0.50/l=
isp/org/ob-matlab<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ma=
kefile hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-makefile<br>c:/Users/=
Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lua hides c:/emacs/share/emacs/3=
0.0.50/lisp/org/ob-lua<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/=
ob-lob hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lob<br>c:/Users/Mitch=
ell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lisp hides c:/emacs/share/emacs/30.0.=
50/lisp/org/ob-lisp<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-=
lilypond hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lilypond<br>c:/User=
s/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-latex hides c:/emacs/share/ema=
cs/30.0.50/lisp/org/ob-latex<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9=
.6.30/ob-julia hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-julia<br>c:/U=
sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-js hides c:/emacs/share/ema=
cs/30.0.50/lisp/org/ob-js<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.=
30/ob-java hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-java<br>c:/Users/=
Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-haskell hides c:/emacs/share/ema=
cs/30.0.50/lisp/org/ob-haskell<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org=
-9.6.30/ob-groovy hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-groovy<br>=
c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-gnuplot hides c:/emacs/=
share/emacs/30.0.50/lisp/org/ob-gnuplot<br>c:/Users/Mitchell/Emacs/.emacs.d=
/elpa/org-9.6.30/ob-fortran hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-=
fortran<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-forth hides =
c:/emacs/share/emacs/30.0.50/lisp/org/ob-forth<br>c:/Users/Mitchell/Emacs/.=
emacs.d/elpa/org-9.6.30/ob-exp hides c:/emacs/share/emacs/30.0.50/lisp/org/=
ob-exp<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-eval hides c:=
/emacs/share/emacs/30.0.50/lisp/org/ob-eval<br>c:/Users/Mitchell/Emacs/.ema=
cs.d/elpa/org-9.6.30/ob-eshell hides c:/emacs/share/emacs/30.0.50/lisp/org/=
ob-eshell<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-emacs-lisp=
 hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-emacs-lisp<br>c:/Users/Mitc=
hell/Emacs/.emacs.d/elpa/org-9.6.30/ob-dot hides c:/emacs/share/emacs/30.0.=
50/lisp/org/ob-dot<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-d=
itaa hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ditaa<br>c:/Users/Mitch=
ell/Emacs/.emacs.d/elpa/org-9.6.30/ob-css hides c:/emacs/share/emacs/30.0.5=
0/lisp/org/ob-css<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-co=
re hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-core<br>c:/Users/Mitchell=
/Emacs/.emacs.d/elpa/org-9.6.30/ob-comint hides c:/emacs/share/emacs/30.0.5=
0/lisp/org/ob-comint<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob=
-clojure hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-clojure<br>c:/Users=
/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-calc hides c:/emacs/share/emacs=
/30.0.50/lisp/org/ob-calc<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.=
30/ob-C hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-C<br>c:/Users/Mitche=
ll/Emacs/.emacs.d/elpa/org-9.6.30/ob-awk hides c:/emacs/share/emacs/30.0.50=
/lisp/org/ob-awk<br><br>Features:<br>(shadow sort mail-extr emacsbug messag=
e yank-media puny rfc822 mml<br>mml-sec epa derived gnus-util mm-decode mm-=
bodies mm-encode mail-parse<br>rfc2231 mailabbrev gmm-utils mailheader send=
mail rfc2047 rfc2045<br>ietf-drums mm-util mail-prsvr mail-utils org ob ob-=
tangle ob-ref ob-lob<br>ob-table ob-exp org-macro org-src ob-comint org-pco=
mplete pcomplete<br>org-list org-footnote org-faces org-entities time-date =
noutline outline<br>ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx=
 org-fold<br>org-fold-core org-keys oc org-loaddefs find-func cal-menu cale=
ndar<br>cal-loaddefs org-version org-compat org-macs format-spec counsel xd=
g<br>xref project dired dired-loaddefs compile text-property-search comint<=
br>ansi-osc ansi-color swiper ivy delsel ring ivy-faces ivy-overlay colir<b=
r>color modus-vivendi-theme modus-themes cl-extra help-mode tab-line<br>use=
-package use-package-ensure use-package-delight use-package-diminish<br>use=
-package-bind-key bind-key use-package-core finder-inf easy-mmode epg<br>rf=
c6068 epg-config gnu-elpa-keyring-update pdf-tools-autoloads<br>tablist-aut=
oloads info package browse-url url url-proxy url-privacy<br>url-expand url-=
methods url-history url-cookie generate-lisp-file<br>url-domsuf url-util ma=
ilcap url-handlers url-parse auth-source cl-seq<br>eieio eieio-core cl-macs=
 password-cache json subr-x map byte-opt gv<br>bytecomp byte-compile url-va=
rs cus-edit pp cus-start cus-load icons<br>wid-edit cl-loaddefs cl-lib rmc =
iso-transl tooltip cconv eldoc paren<br>electric uniquify ediff-hook vc-hoo=
ks lisp-float-type elisp-mode mwheel<br>dos-w32 ls-lisp disp-table term/w32=
-win w32-win w32-vars term/common-win<br>tool-bar dnd fontset image regexp-=
opt fringe tabulated-list replace<br>newcomment text-mode lisp-mode prog-mo=
de register page tab-bar menu-bar<br>rfn-eshadow isearch easymenu timer sel=
ect scroll-bar mouse jit-lock<br>font-lock syntax font-core term/tty-colors=
 frame minibuffer nadvice seq<br>simple cl-generic indonesian philippine ch=
am georgian utf-8-lang<br>misc-lang vietnamese tibetan thai tai-viet lao ko=
rean japanese eucjp-ms<br>cp51932 hebrew greek romanian slovak czech europe=
an ethiopic indian<br>cyrillic chinese composite emoji-zwj charscript charp=
rop case-table<br>epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-pr=
eloaded button<br>loaddefs theme-loaddefs faces cus-face macroexp files win=
dow<br>text-properties overlay sha1 md5 base64 format env code-pages mule<b=
r>custom widget keymap hashtable-print-readable backquote threads<br>w32not=
ify w32 lcms2 multi-tty move-toolbar make-network-process<br>native-compile=
 emacs)<br><br>Memory information:<br>((conses 16 476739 29195) (symbols 48=
 26493 0)<br>=C2=A0(strings 32 133104 6737) (string-bytes 1 3784773) (vecto=
rs 16 33874)<br>=C2=A0(vector-slots 8 430476 21000) (floats 8 269 15) (inte=
rvals 56 554 0)<br>=C2=A0(buffers 992 12))<div><div dir=3D"ltr" class=3D"gm=
ail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><br></di=
v></div></div></div>

--000000000000b4d60d061b376e60--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Mitchell <mitchellahren@HIDDEN>
Subject: bug#71644: Acknowledgement (30.0.50; Severe slowdown in larger
 files with markers beginning in emacs 29+)
Message-ID: <handler.71644.B.171878417716213.ack <at> debbugs.gnu.org>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
X-Gnu-PR-Message: ack 71644
X-Gnu-PR-Package: emacs
Reply-To: 71644 <at> debbugs.gnu.org
Date: Wed, 19 Jun 2024 08:03:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 71644 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
71644: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D71644
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jun 2024 12:58:02 +0000
Resent-Message-ID: <handler.71644.B71644.171880184128954 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Mitchell <mitchellahren@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Date: Wed, 19 Jun 2024 15:56:44 +0300
Message-Id: <86ed8tozub.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 (message from Mitchell on Tue, 18 Jun 2024 23:25:18 -0600)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jun 2024 13:48:01 +0000
Resent-Message-ID: <handler.71644.B71644.17188912613896 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <86ed8tozub.fsf@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
Date: Thu, 20 Jun 2024 13:49:10 +0000
Message-ID: <87ed8r912h.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Eli Zaretskii <eliz@HIDDEN> writes:

> 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?

What if you add
(setq org-fold-core-style 'text-properties) to your reproducer?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jun 2024 16:13:03 +0000
Resent-Message-ID: <handler.71644.B71644.171889993424233 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171889993424233
          (code B ref 71644); Thu, 20 Jun 2024 16:13:03 +0000
Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 16:12:14 +0000
Received: from localhost ([127.0.0.1]:34909 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKKOT-0006Im-KY
	for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:12:13 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41084)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sKKOQ-0006IV-N8
 for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:12:11 -0400
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 <eliz@HIDDEN>)
 id 1sKKOD-0000Io-85; Thu, 20 Jun 2024 12:11:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=njrTgbcnkC0luF79xq8yksVLn64lnqxIALUMMTguPlw=; b=AUuOJdzNI1DS
 lm7UK1oE96ahHzmoolmV0ZwSDHQalt7hyOJTaVPHROdAL4e56+CIDeTFRmn0/1TetNbsbl1XaCqxu
 ZFDwuwBVJtuUcNq9zTW7prnP1R70HfGIFSwJr1XKqUgzm4VD/vGbqkYYj5DcUJ6OJTAFegKeqFIZY
 +GeKZ0U6Otr3Qq1rdjmv76HS4xRN0a5J4MxvaSWd2GJSX4TOpt63mi5Y9buzSChtjB9MzmOkg8h+K
 0BRqRFQA1et09x0nM2RRrWihCLm/cka7vVbD1FE8E4iZ2MrEMc0/a1LubRa+WHob2yTlLjk928jR6
 ALj0UH6AyHiN9kio8vSGxA==;
Date: Thu, 20 Jun 2024 19:11:28 +0300
Message-Id: <86wmmjmw5r.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87ed8r912h.fsf@localhost> (message from Ihor Radchenko on Thu,
 20 Jun 2024 13:49:10 +0000)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN> <87ed8r912h.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
> Date: Thu, 20 Jun 2024 13:49:10 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> > 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?
> 
> What if you add
> (setq org-fold-core-style 'text-properties) to your reproducer?

Then abbrevs don't work (not sure I understand why), so I cannot run
the recipe.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jun 2024 16:25:01 +0000
Resent-Message-ID: <handler.71644.B71644.171890067625844 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: yantar92@HIDDEN, mitchellahren@HIDDEN
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171890067625844
          (code B ref 71644); Thu, 20 Jun 2024 16:25:01 +0000
Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 16:24:36 +0000
Received: from localhost ([127.0.0.1]:35323 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKKaS-0006im-72
	for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:24:36 -0400
Received: from eggs.gnu.org ([209.51.188.92]:57794)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sKKaP-0006iT-4p
 for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:24:34 -0400
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 <eliz@HIDDEN>)
 id 1sKKaE-0002Vb-Ly; Thu, 20 Jun 2024 12:24:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=25QGlx6bVOJrABu1oy3gESGJ00jbJPD2SxwwaxHUStI=; b=PDJoFZ8EGIO2
 rO4nAWoH35XPQ+70UwWAiCVHTPtA0JtyI5ZqSQJqnzjqc8LewhlK6/Iq0XaHvu2Ci0wG4V5ZkdzC2
 2FKLVlikn9IUZwCnS3S9X9yEz1SADE1132DfLEhdWC13F4f6Y/qUT+Dw62/CTwfGxqwxppZ7VbjpN
 bmPichtAaznKnNFf8u44HQ/PqY1heCqnXB9CrOdn922TIYZ3VJnWOp2thDOxrDfqcXdQlWlv56OBW
 321MVV/dcu44ZJ0U4seTP0VfmqyDv22aShP/etxVb4cYbnevWvQHAARBaPaRpA/DR+oClBVmyoBrT
 KiVKj5+2n6iY93v0AcuECg==;
Date: Thu, 20 Jun 2024 19:24:02 +0300
Message-Id: <86v823mvkt.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <86wmmjmw5r.fsf@HIDDEN> (message from Eli Zaretskii on Thu, 20
 Jun 2024 19:11:28 +0300)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN> <87ed8r912h.fsf@localhost> <86wmmjmw5r.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
> Date: Thu, 20 Jun 2024 19:11:28 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> > From: Ihor Radchenko <yantar92@HIDDEN>
> > Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
> > Date: Thu, 20 Jun 2024 13:49:10 +0000
> > 
> > Eli Zaretskii <eliz@HIDDEN> writes:
> > 
> > > 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?
> > 
> > What if you add
> > (setq org-fold-core-style 'text-properties) to your reproducer?
> 
> Then abbrevs don't work (not sure I understand why), so I cannot run
> the recipe.

Sorry, that was a cockpit error.  Now that I fixed that, I can report
that the setting you suggested doesn't change anything: I see no
delays in Emacs 30.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jun 2024 19:05:02 +0000
Resent-Message-ID: <handler.71644.B71644.17189102873507 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Mitchell <mitchellahren@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17189102873507
          (code B ref 71644); Thu, 20 Jun 2024 19:05:02 +0000
Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 19:04:47 +0000
Received: from localhost ([127.0.0.1]:40665 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKN5S-0000uT-Rq
	for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 15:04:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:45830)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sKN5R-0000uA-7j
 for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 15:04:45 -0400
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 <eliz@HIDDEN>)
 id 1sKN5H-0000Zh-LM; Thu, 20 Jun 2024 15:04:35 -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=+gOzL+/K0V4fEvwgUvMChViidGJku0nNXNftSADStNo=; b=f5PzIu1bI8eaSCnCLDK5
 CeqgyJ3VQBFycesOLGKDkw5I20gwmGH4oDXvdXe3CAeZzbTIVp5zv/NDov+3OIjn2Sc6Kv7J5mAJR
 9DAqWn95ht92qZ/O7wHwtsj0M7dRtGjIaTSU0WChjFCGyrvBt17mqN43h1m4hE0pLeQ7gbMplfq4A
 Bx9baU+1GTUNMx3DXao6FCgrYtn0A4Gx9yBfUboDO6YvGMMJ+mM5cZnedhzor37Fjo3dNV4jpz9Rl
 xO26pUMvHeF49IaYGG1f9t+kqFPry1qbpRLmWC285pbAzZ3GTMTKHUMS96iDGv2TmRMUzLmNIe28L
 QXCrIBlGVuy3QA==;
Date: Thu, 20 Jun 2024 22:04:33 +0300
Message-Id: <86jzijmo5a.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 (message from Mitchell on Thu, 20 Jun 2024 12:57:58 -0600)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Mitchell <mitchellahren@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jun 2024 21:43:02 +0000
Resent-Message-ID: <handler.71644.B71644.17189197411644 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17189197411644
          (code B ref 71644); Thu, 20 Jun 2024 21:43:02 +0000
Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 21:42:21 +0000
Received: from localhost ([127.0.0.1]:45201 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKPXw-0000QQ-Iz
	for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 17:42:21 -0400
Received: from mail-ed1-f42.google.com ([209.85.208.42]:46511)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mitchellahren@HIDDEN>) id 1sKN0a-0006LC-Ux
 for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 14:59:46 -0400
Received: by mail-ed1-f42.google.com with SMTP id
 4fb4d7f45d1cf-57d10354955so1313901a12.1
 for <71644 <at> 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)
MIME-Version: 1.0
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
In-Reply-To: <86ed8tozub.fsf@HIDDEN>
From: Mitchell <mitchellahren@HIDDEN>
Date: Thu, 20 Jun 2024 12:57:58 -0600
Message-ID: <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000e0179f061b56e6b6"
X-Spam-Score: -0.0 (/)
X-Mailman-Approved-At: Thu, 20 Jun 2024 17:42:19 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--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 <eliz@HIDDEN> wrote:

> > From: Mitchell <mitchellahren@HIDDEN>
> > 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

<div dir=3D"ltr"><div>Thank you for the response, Eli. <br></div><div><br><=
/div><div>&gt; Maybe the reason is that Emacs 30 now<br>&gt; uses Org 9.7.4=
, whereas you have a local installation of 9.6.30? <br></div><div><br></div=
><div>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. <br></=
div><div><br></div><div class=3D"">
&gt;=20
=20


Why did you decide the problem was due to markers?=C2=A0 I see a single<br>
&gt;=20
=20


change in the implementation of markers in Emacs 29 as compared to<br>
&gt;=20
=20


Emacs 28, and no changes at all in Emacs 30 (except one that affects<br>

&gt;=20
=20

the Android, I think). <br></div><div><br></div><div>I thought it was marke=
rs because (1) overwriting a few functions in counsel.el to be the versions=
 at <a href=3D"https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba=
7260" target=3D"_blank">https://gist.github.com/kings2u/5a8acbf0986f0848be6=
6169d2dba7260</a> 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...)<br></div><div><br></div><div>&gt;=20
 I _can_ reproduce this in Emacs 29.3, where indeed<br>
&gt;=20


expanding any of the two abbrevs takes about 0.5 sec to show on the<br>
&gt;=20


screen.=C2=A0 <br></div><div><br></div><div>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?</=
div><div><br></div><div>
&gt;=20
=20


I see 3400 markers created by counsel-outline in this case, which is<br>
&gt;=20
=20


not too many, IMO. <br></div><div><br></div><div>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.<br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 19, 2024=
 at 6:57=E2=80=AFAM Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN" targe=
t=3D"_blank">eliz@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">&gt; From: Mitchell &lt;<a href=3D"mailto:mitchell=
ahren@HIDDEN" target=3D"_blank">mitchellahren@HIDDEN</a>&gt;<br>
&gt; Date: Tue, 18 Jun 2024 23:25:18 -0600<br>
&gt; <br>
&gt; I recently upgraded from emacs 28.2 to 29.3. When I resumed working in=
 a large 11MB org-mode file that<br>
&gt; never gave me problems with speed on 28.2, I noticed a severe slowdown=
 when editing the buffer after<br>
&gt; invoking `counsel-outline`. It took a while for me to isolate the issu=
e, but it seems to be caused by the many<br>
&gt; markers that `counsel-outline` creates in the buffer. After invoking t=
he command, every subsequent edit to the<br>
&gt; buffer renders much slower on screen than it did in 28.2.<br>
&gt; <br>
&gt; This problem is not only caused by `counsel-outline`, but other functi=
ons that create a lot of markers in the<br>
&gt; buffer, like `org-refile` if `org-refile-use-cache` is set to `t`. I t=
ried upgrading my system to emacs 30.0.50,<br>
&gt; which I&#39;ve used to generate this bug report, but the issue persist=
s. <br>
<br>
I cannot reproduce this on my system, with the current master branch,<br>
i.e. Emacs 30.=C2=A0 I _can_ reproduce this in Emacs 29.3, where indeed<br>
expanding any of the two abbrevs takes about 0.5 sec to show on the<br>
screen.=C2=A0 But in Emacs 30 it&#39;s instantaneous, even though I used an=
<br>
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?<br>
<br>
Why did you decide the problem was due to markers?=C2=A0 I see a single<br>
change in the implementation of markers in Emacs 29 as compared to<br>
Emacs 28, and no changes at all in Emacs 30 (except one that affects<br>
the Android, I think).<br>
<br>
&gt; Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and=
 5, and then `profiler-stop` after Step<br>
&gt; 7, I get a very big entry (e.g., 70%) for `redisplay_internal (C funct=
ion)` in the `profiler-report`. Using the<br>
&gt; `profiler` at the same points using emacs 28.2, I don=E2=80=99t get a =
big entry for `redisplay_internal (C function)`.<br>
<br>
This doesn&#39;t necessarily mean the problem is due to the markers (but<br=
>
doesn&#39;t refute that, either).<br>
<br>
I see 3400 markers created by counsel-outline in this case, which is<br>
not too many, IMO.<br>
<br>
&gt; Here are the steps to reproduce the issue:<br>
&gt; <br>
&gt; 1. Start emacs 29.3 (or 30.0.50) with emacs -q.<br>
&gt; 2. Paste the minimal config at <a href=3D"https://gist.github.com/king=
s2u/30b7a22dfa38fe0d5dc18adaf0e5e9de" rel=3D"noreferrer" target=3D"_blank">=
https://gist.github.com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de</a> into t=
he<br>
&gt; scratch buffer and eval-buffer. (Note on my system I&#39;m using the `=
counsel` version current as of<br>
&gt; counsel-20240502.743, but any recent version will reproduce the bug).<=
br>
&gt; 3. Open the following big file in org-mode:<br>
&gt; <a href=3D"https://gist.github.com/kings2u/c123a30de7e507a153a9500f03f=
08a9e" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/kings2u=
/c123a30de7e507a153a9500f03f08a9e</a><br>
&gt; 4. `goto-line` 35.<br>
&gt; 5. `M-x counsel-outline` and simply press enter to navigate point to t=
he headline at line 34.<br>
&gt; 6. Go to the end of the line and press `enter` to start typing on a ne=
w line at line 35.<br>
&gt; 7. Start typing `n` `space`, or `t` `space` several times very fast an=
d observe how long it takes for the abbrev<br>
&gt; expansions (defined in the minimal config above) to show up on the scr=
een.<br>
<br>
I didn&#39;t want to install all those packages (counsel is just the tip<br=
>
of the iceberg, it wants you to install ivy and swiper and whatnot),<br>
so I simply unpacked their tarballs from ELPA, and did this instead of<br>
steps 1 and 2 above:<br>
<br>
=C2=A0 (add-to-list &#39;load-path &quot;~/foo/ivy-0.14.2&quot;)<br>
=C2=A0 (add-to-list &#39;load-path &quot;~/foo/swiper-0.14.2&quot;)<br>
=C2=A0 (setq-default abbrev-mode t)<br>
=C2=A0 (setq save-abbrevs nil)<br>
=C2=A0 (add-hook &#39;minibuffer-setup-hook (lambda () (setq-local abbrev-m=
ode nil)))<br>
=C2=A0 (define-abbrev global-abbrev-table &quot;n&quot; &quot;and&quot;)<br=
>
=C2=A0 (define-abbrev global-abbrev-table &quot;t&quot; &quot;the&quot;)<br=
>
=C2=A0 (define-abbrev global-abbrev-table &quot;th&quot; &quot;that&quot;)<=
br>
<br>
=C2=A0 M-x load-file RET ~/foo/counsel-0.14.2/counsel.el RET<br>
=C2=A0 M-x eval-region RET<br>
<br>
Then I did all the rest of steps.=C2=A0 As mentioned, I do see the slow<br>
responses in Emacs 29.3, but not in the latest master branch of the<br>
Emacs Git repository.<br>
</blockquote></div>

--000000000000e0179f061b56e6b6--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Mitchell <mitchellahren@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jun 2024 02:49:01 +0000
Resent-Message-ID: <handler.71644.B71644.171893812117993 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171893812117993
          (code B ref 71644); Fri, 21 Jun 2024 02:49:01 +0000
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 02:48:41 +0000
Received: from localhost ([127.0.0.1]:53188 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKUKO-0004g5-QE
	for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 22:48:41 -0400
Received: from mail-lj1-f170.google.com ([209.85.208.170]:47521)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mitchellahren@HIDDEN>) id 1sKUKM-0004fr-OB
 for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 22:48:39 -0400
Received: by mail-lj1-f170.google.com with SMTP id
 38308e7fff4ca-2eaafda3b5cso17077531fa.3
 for <71644 <at> 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)
MIME-Version: 1.0
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
In-Reply-To: <86jzijmo5a.fsf@HIDDEN>
From: Mitchell <mitchellahren@HIDDEN>
Date: Thu, 20 Jun 2024 20:46:51 -0600
Message-ID: <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000bf7750061b5d73dc"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--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 <eliz@HIDDEN> wrote:

> > From: Mitchell <mitchellahren@HIDDEN>
> > 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 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

<div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smart=
mail=3D"gmail_signature"><div dir=3D"ltr"><div class=3D"">&gt; If you remov=
e all the non-ASCII characters from the Org file, does the<br>
&gt;=20

slowdown go away?<span class=3D"gmail-im"><br></span></div><div class=3D"">=
<span class=3D"gmail-im"><br></span></div><div class=3D""><span class=3D"gm=
ail-im">Eli, that solved it! The new test file is at </span><a href=3D"http=
s://gist.github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2">https://gist.=
github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2</a>. <span class=3D"gma=
il-im">I replaced every </span>
non-ASCII character with an &quot;a&quot; 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!<br></div><div class=3D""><br></div><div class=3D"">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? <br></div><div cla=
ss=3D""><br></div><div class=3D"">Thank you again!<br></div></div></div></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Thu, Jun 20, 2024 at 1:04=E2=80=AFPM Eli Zaretskii &lt;<a href=3D"mai=
lto:eliz@HIDDEN">eliz@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">&gt; From: Mitchell &lt;<a href=3D"mailto:mit=
chellahren@HIDDEN" target=3D"_blank">mitchellahren@HIDDEN</a>&gt;<br>
&gt; Date: Thu, 20 Jun 2024 12:57:58 -0600<br>
&gt; Cc: <a href=3D"mailto:71644 <at> debbugs.gnu.org" target=3D"_blank">71644@d=
ebbugs.gnu.org</a><br>
&gt; <br>
&gt; &gt; Why did you decide the problem was due to markers?=C2=A0 I see a =
single<br>
&gt; &gt; change in the implementation of markers in Emacs 29 as compared t=
o<br>
&gt; &gt; Emacs 28, and no changes at all in Emacs 30 (except one that affe=
cts<br>
&gt; &gt; the Android, I think). <br>
&gt; <br>
&gt; I thought it was markers because (1) overwriting a few functions in co=
unsel.el to be the versions at<br>
&gt; <a href=3D"https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2db=
a7260" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/kings2u=
/5a8acbf0986f0848be66169d2dba7260</a> so that counsel-outline cleaned up th=
e<br>
&gt; markers it created caused the bug to go away, and (2) the bug also exi=
sts when instead of counsel-outline at<br>
&gt; Step 5 I used org-refile (with `org-refile-use-cache` is set to `t`), =
and `org-refile-use-cache` seems to create<br>
&gt; many markers in the buffer. But maybe counsel-outline and org-refile a=
re both doing something else that<br>
&gt; cause the bug. (FWIW I did also notice that the abbrev expansions were=
 slightly quicker in Step 7 after using<br>
&gt; org-refile than after counsel-outline...)<br>
<br>
If you remove all the non-ASCII characters from the Org file, does the<br>
slowdown go away?<br>
<br>
&gt; &gt; I _can_ reproduce this in Emacs 29.3, where indeed<br>
&gt; &gt; expanding any of the two abbrevs takes about 0.5 sec to show on t=
he<br>
&gt; &gt; screen.=C2=A0 <br>
&gt; <br>
&gt; Abbrev expansions on my machine take longer. When I re-create the bug =
with counsel-outline, the abbrevs<br>
&gt; take over a second each to expand. Maybe your hardware is faster than =
mine?<br>
<br>
Could be, but twice slower sounds too much to be explained by CPU<br>
speed.<br>
<br>
&gt; &gt; I see 3400 markers created by counsel-outline in this case, which=
 is<br>
&gt; &gt; not too many, IMO. <br>
&gt; <br>
&gt; 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<br>
&gt; docs or online.<br>
<br>
There&#39;s a function count_markers in Emacs, it just isn&#39;t compiled<b=
r>
unless you compile with -DDEBUG_MARKERS=3D1.=C2=A0 So I compiled it and<br>
called it from GDB.<br>
</blockquote></div>

--000000000000bf7750061b5d73dc--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jun 2024 06:18:01 +0000
Resent-Message-ID: <handler.71644.B71644.171895065110379 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Mitchell <mitchellahren@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171895065110379
          (code B ref 71644); Fri, 21 Jun 2024 06:18:01 +0000
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 06:17:31 +0000
Received: from localhost ([127.0.0.1]:56675 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKXaU-0002hK-U8
	for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:17:31 -0400
Received: from mout01.posteo.de ([185.67.36.65]:56271)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sKXaS-0002h4-CW
 for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:17:29 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 45632240028
 for <71644 <at> debbugs.gnu.org>; Fri, 21 Jun 2024 08:17:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1718950638; bh=p/bafi0s/IVL59N0a7/DDyV67Fu2QwH8eF99U0uh2YE=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=EVA9jjZPI9AS/yNpksmwxYnhmqMFV+w0ka0KLA1z7FPH6Ar2PZsnDi8HsA5FgR00n
 k9/0eLvJC+kSsIT1frBWSsgrUJ5cz1aO5Q6lWqxX8EYEmL8F43syYScRBxJzFzUVAP
 jomODkajm0bwOY0HnpvL+z6xBclawcXkBgJYwgGzc8rCU+gl/udqXxAwIvUL1Lkx+d
 di049qcdXUTFCUAZKX0r3rc2/OcsXpJ4V6S41ToX0slaZRPLJBHspkF8PXIp8edTVt
 bNf1C3yb4nhTqVHfxjR/7qVdGGWGlV8RxZkPDDINbdds0e8GwTEO04n+kgNL6Qu53C
 2LIpgSuO9MYOQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W56b13G9lz9rxR;
 Fri, 21 Jun 2024 08:17:17 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
Date: Fri, 21 Jun 2024 06:19:01 +0000
Message-ID: <87h6dmbyy2.fsf@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

--=-=-=
Content-Type: text/plain

Mitchell <mitchellahren@HIDDEN> writes:

>> 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!

Hmm. Then, does the attached patch help?


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-src-marker.c-buf_bytepos_to_charpos-Limit-marker-sea.patch

From 0bafd288faee8cae33fe4a122f6e3ac73ec10d60 Mon Sep 17 00:00:00 2001
Message-ID: <0bafd288faee8cae33fe4a122f6e3ac73ec10d60.1718950719.git.yantar92@HIDDEN>
From: Ihor Radchenko <yantar92@HIDDEN>
Date: Sun, 23 Apr 2023 21:31:46 +0200
Subject: [PATCH] * src/marker.c (buf_bytepos_to_charpos): Limit marker search

Limit searching across buffer markers to first 50 markers and thus
avoid performance scaling with the number of markers.

I got 5x `re-search-forward' speed improvement in my setup with this
dumb change.
---
 src/marker.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/marker.c b/src/marker.c
index f016bf9c088..4d7d6621513 100644
--- a/src/marker.c
+++ b/src/marker.c
@@ -354,8 +354,10 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t bytepos)
   if (b == cached_buffer && BUF_MODIFF (b) == cached_modiff)
     CONSIDER (cached_bytepos, cached_charpos);
 
-  for (tail = BUF_MARKERS (b); tail; tail = tail->next)
+  int i = 0;
+  for (tail = BUF_MARKERS (b); tail && i < 50; tail = tail->next)
     {
+      i++;
       CONSIDER (tail->bytepos, tail->charpos);
 
       /* If we are down to a range of 50 chars,
-- 
2.45.1


--=-=-=
Content-Type: text/plain


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jun 2024 06:50:02 +0000
Resent-Message-ID: <handler.71644.B71644.171895255613372 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Mitchell <mitchellahren@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171895255613372
          (code B ref 71644); Fri, 21 Jun 2024 06:50:02 +0000
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 06:49:16 +0000
Received: from localhost ([127.0.0.1]:56716 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKY5D-0003Tc-Ja
	for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:49:15 -0400
Received: from eggs.gnu.org ([209.51.188.92]:46302)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sKY5B-0003TO-U0
 for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:49:15 -0400
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 <eliz@HIDDEN>)
 id 1sKY52-0002oj-1n; Fri, 21 Jun 2024 02:49:04 -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=Z0J8aPuHrE+3ohIFzBCUze+l9/TkY/EFX7Xi8cdRR5w=; b=DHd/MskpgbARbUXnUWzR
 9BluJGLN2atV2zlCB11Rcj9vklRIl/2ghgmajBiXl1Atmaq9Qcwxl0BMC4OXiVzccymVRi7tkFT1e
 anBwoLk4hdV1ow74skNhbPfZsICOeeLDk5CJgifcFdkBidntv3bqmUAb0LJgNDVLT++Y/bHRGgUii
 vQPsKV73CONAd0b7wbIgVj/fhsqob/F068/Ve58AWdnikyX1kfjDs2B/S+vwvPj0j6o2mtZOxYnFB
 9H/xI1VgMuiifsw4WEBKh0JLiEO82+JZ8In6jHnEKvNKT68KdSR3eKmYVYS70w0RuVmb+jSo62Jhu
 TOYxGSjlNxzWaQ==;
Date: Fri, 21 Jun 2024 09:48:58 +0300
Message-Id: <86y16ylrj9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 (message from Mitchell on Thu, 20 Jun 2024 20:46:51 -0600)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Mitchell <mitchellahren@HIDDEN>
> Date: Thu, 20 Jun 2024 20:46:51 -0600
> Cc: 71644 <at> debbugs.gnu.org
> 
> > 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’s going on in the backend so bigger buffers with markers and
> non-ASCII characters don’t exhibit this slowness in the latest emacs? 

The fact that the problem goes away when you remove non-ASCII
characters is a pretty convincing argument in favor of your theory
that markers are involved.  Because Emacs consults the buffer's
markers whenever it needs to convert character positions to byte
positions or vice versa, which is done _a_lot_.

The only significant change I see in markers code that could be
related to converting character to byte positions is this:

  commit 8783700b23e70874c4996908bf02c010ae6f3fe1
  Author:     Stefan Monnier <monnier@HIDDEN>
  AuthorDate: Tue Aug 2 10:38:53 2022 -0400
  Commit:     Stefan Monnier <monnier@HIDDEN>
  CommitDate: Tue Aug 2 13:06:51 2022 -0400

      * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1

It changed the comparison operator in two places in marker.c.

Curiously, the log message doesn't even mention the change in
marker.c, which could be a sign that this change was not intended to
be installed.  Stefan, did you intend to install it, and if so, do you
have any comments about this bug report?

I'm a bit confused by the fact that I don't see the slowdown on my
machine, but maybe there are other factors at work here that hide the
regression.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jun 2024 20:54:02 +0000
Resent-Message-ID: <handler.71644.B71644.171900319719646 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171900319719646
          (code B ref 71644); Fri, 21 Jun 2024 20:54:02 +0000
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 20:53:17 +0000
Received: from localhost ([127.0.0.1]:43900 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKlG0-00056o-U0
	for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 16:53:17 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48775)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sKlFx-00056Z-7o
 for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 16:53:15 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6A87880C8E;
 Fri, 21 Jun 2024 16:53:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719003185;
 bh=7AfMU+VaclZfW0lsebWgyaqBfx88fEvVq2+zFEvVelw=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=SLir+/rYCHh0m8eybxj4gw2rEsnZLCHnlvPSVVQmcnLztMfQ+39YjnwNwOpR+Dkpa
 O22Vxnwag5FUVWn46YMRkar6f79k57/esvHdH3ayqweM6IMftK6rIwHCZ7i53/mmBK
 DPaplKDeCRiXaUqatH/S2OlcHWuhMMTw+pexbZBF+sc74zKUwGud7JWiQ/3X451MCD
 6h22oGsAu1h4kauQDg0bV/J7EOt5zWHTvBiUgVb6snMRlUr76sbSh4rcI7XUQ2fH1Z
 l1hs864qZhgfINFG0Wxl43+IjYBtVPJ1mOpIKH2xXmXRaYuXKOa4VR8gBpMSZRO2mn
 8lk6dpu/vP9Rw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D4D46801D8;
 Fri, 21 Jun 2024 16:53:05 -0400 (EDT)
Received: from asado (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8E2781201A6;
 Fri, 21 Jun 2024 16:53:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87h6dmbyy2.fsf@localhost> (Ihor Radchenko's message of "Fri, 21
 Jun 2024 06:19:01 +0000")
Message-ID: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost>
Date: Fri, 21 Jun 2024 16:53:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.087 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>From 0bafd288faee8cae33fe4a122f6e3ac73ec10d60 Mon Sep 17 00:00:00 2001
> Message-ID: <0bafd288faee8cae33fe4a122f6e3ac73ec10d60.1718950719.git.yant=
ar92@HIDDEN>
> From: Ihor Radchenko <yantar92@HIDDEN>
> Date: Sun, 23 Apr 2023 21:31:46 +0200
> Subject: [PATCH] * src/marker.c (buf_bytepos_to_charpos): Limit marker se=
arch
>
> Limit searching across buffer markers to first 50 markers and thus
> avoid performance scaling with the number of markers.
>
> I got 5x `re-search-forward' speed improvement in my setup with this
> dumb change.

Hmm... of course, there'd likely be other circumstances where it would
make it 5x slower.  E.g. in a large buffer, doing a forward search from
the middle of the buffer when the first 50 markers happen to all be near
the beginning of the buffer will mean that we always use the "slow path"
which scans all the bytes between PT and the position of interest to
count the number of chars therein.

BTW, we already stop after at most N/50 markers where N is the smallest
distance between the position of interest and point/bob/eob/gap (oh and
the position of the last conversion).  So it seems that in your test,
this distance N is >2500.  Also when that distance is >5000 we create
a new marker, so next time around that position should be at the
beginning of the marker-list.  So I wonder what happens in your test:
why do we jump "very far" (more than 2500) between each call to the
conversion function?  Also, maybe we should increase
BYTECHAR_DISTANCE_INCREMENT?  ]

This byte_to_char and char_to_byte conversion business is a real PITA.
[ In retrospect I wish we'd stuck to the Emacs-20.1 design where
  chars=3Dbytes.  I know it introduced a lot of breakage (and it'd be even
  worse now), but it is The Right Thing=E2=84=A2 if you can ignore backward
  compatibility.  ]

Using markers as a cheap cache of conversions was a cute hack but we
really need to replace it.

Some options that come to mind:

- Keep the tradition of abusing an existing data structure, and stash
  the bytepos info inside the overlay tree or the text properties.
  This way the conversion is bounded by O(log BUFFERSIZE).

- Use a dedicated data-structure.  E.g. a pair of array-with-a-gap
  (one indexed by BYTEPOS/STEP the other indexed by CHARPOS/STEP, where
  STEP would be a large enough constant to make those arrays cheap yet
  small enough that the remaining scan is cheap).
  This way the conversion is O(STEP), i.e. "constant-time".

BTW, among my various local hacks, I've been using the hack below, which
aims to randomize the order in our markers-list, so as to minimize the
risk that we have to wade through lots of markers all clumped around the
same position.  I don't think it does a good job of it, but maybe we can
improve the execution of this idea, tho it still doesn't help if there's
no GC involved.

BTW, if/when we use some other data-structure to convert bytes<->chars,
then we could presumably get rid of our markers-list and stash markers
inside our overlay tree (basically represent them as degenerate overlays
with beg=3D=3Dend and no properties).


        Stefan


diff --git a/src/alloc.c b/src/alloc.c
index 9304e4e42bb..07409e7cfc3 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7836,10 +7514,22 @@ sweep_symbols (void)
 unchain_dead_markers (struct buffer *buffer)
 {
   struct Lisp_Marker *this, **prev =3D &BUF_MARKERS (buffer);
+  /* In order to try and avoid worst case behaviors in buf_charpos_to_byte=
pos
+     we try and randomize the order of markers here.  */
+  unsigned i =3D 4;
=20
   while ((this =3D *prev))
     if (vectorlike_marked_p (&this->header))
-      prev =3D &this->next;
+      {
+        if (!shuffle_markers || i++ % 8)
+          prev =3D &this->next;
+        else
+          { /* Move this one to front, just to shuffle things a bit.  */
+            *prev =3D this->next;
+            this->next =3D BUF_MARKERS (buffer);
+            BUF_MARKERS (buffer) =3D this;
+          }
+      }
     else
       {
         this->buffer =3D NULL;

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jun 2024 21:07:02 +0000
Resent-Message-ID: <handler.71644.B71644.171900400120901 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171900400120901
          (code B ref 71644); Fri, 21 Jun 2024 21:07:02 +0000
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 21:06:41 +0000
Received: from localhost ([127.0.0.1]:43914 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKlSz-0005R3-1W
	for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 17:06:41 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26745)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sKlSw-0005Qp-TO
 for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 17:06:39 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D836980C8E;
 Fri, 21 Jun 2024 17:06:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719003992;
 bh=81OivFs9r+nGAZQWPRJLhFVkh+8Iikb80wJuUJcMCFo=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=CYxWo/mmCerOGaEVPLuPR1HQbCCB1VfOX/2Iu9kZKiYFfkpQAxIEy9cZIkb4trPvd
 EZbRrQot0RY6FeTLV4q0HAXmdkjRmERepMFVHq2axC7dK8dMZhoozMvLl/ZGWxJhyZ
 dl5YtT4RWbK8XJLBDGgwwasVGXQ4MDsPjfGEBG/GSWBHMMrfR5EWHxX7Fb209ocUpJ
 C79tQRJH+w79YdBoBUch1RfKUkeye1aOL+LcxNcGh4x4MbfJKpkOUullT66Ca42FBT
 NIFEoY/+p3ZFwwz2Dh6aP0eESdDCyM4D4BRDn3KwJYuirr7DJZpoCeRXl7vcTFmNY6
 B1hq9noPuhE2A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A7940807F5;
 Fri, 21 Jun 2024 17:06:32 -0400 (EDT)
Received: from asado (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 61AE51202B5;
 Fri, 21 Jun 2024 17:06:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <86y16ylrj9.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 21 Jun
 2024 09:48:58 +0300")
Message-ID: <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <86y16ylrj9.fsf@HIDDEN>
Date: Fri, 21 Jun 2024 17:06:31 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.086 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>   commit 8783700b23e70874c4996908bf02c010ae6f3fe1
>   Author:     Stefan Monnier <monnier@HIDDEN>
>   AuthorDate: Tue Aug 2 10:38:53 2022 -0400
>   Commit:     Stefan Monnier <monnier@HIDDEN>
>   CommitDate: Tue Aug 2 13:06:51 2022 -0400
>
>       * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1
>
> It changed the comparison operator in two places in marker.c.
>
> Curiously, the log message doesn't even mention the change in
> marker.c, which could be a sign that this change was not intended to
> be installed.  Stefan, did you intend to install it, and if so, do you
> have any comments about this bug report?

Hmm... can't remember why/how it ended up in the above commit.
Looks like an oversight.  But the change should be harmless: the
`eassert` should make sure that the comparison gives the same answer
either way (and AFAICT if/when the new comparison gives a different
answer from the old code, the old code will loop until it segfaults).

> I'm a bit confused by the fact that I don't see the slowdown on my
> machine, but maybe there are other factors at work here that hide
> the regression.

The byte<->char conversion code is affected by many unrelated moving
parts, so it can be difficult to come up with a reproducible recipe.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 05:25:01 +0000
Resent-Message-ID: <handler.71644.B71644.171903386512675 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 71644 <at> debbugs.gnu.org
Cc: mitchellahren@HIDDEN, yantar92@HIDDEN, eliz@HIDDEN, monnier@HIDDEN
X-Debbugs-Original-To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-Debbugs-Original-Cc: Mitchell <mitchellahren@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171903386512675
          (code B ref 71644); Sat, 22 Jun 2024 05:25:01 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 05:24:25 +0000
Received: from localhost ([127.0.0.1]:44132 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKtEe-0003IN-Oc
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:24:24 -0400
Received: from mail-ej1-f43.google.com ([209.85.218.43]:54318)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gerd.moellmann@HIDDEN>) id 1sKtEb-0003I9-MX
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:24:23 -0400
Received: by mail-ej1-f43.google.com with SMTP id
 a640c23a62f3a-a6ef46d25efso305585766b.0
 for <71644 <at> debbugs.gnu.org>; Fri, 21 Jun 2024 22:24:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719033796; x=1719638596; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=;
 b=KVHyxtT4fexhBZ/n9ZsV6nzg1pezRKXUOQOTeTD9+lVu+SrqjFbkO2JyAx5eBQlAUV
 C5ayk3/ZC9wyLyftBW0Q2zUuyGnP6WsEwnUayLGYYn6ESbzBeZged1xCONppzHlAI/vh
 hfl618WgZCMRYjvr+lCBCCfan4CupVWsJE97VaY5dC7yf0EouM6KC1ZlqGxcpGpkniDj
 q48/Z4TEuhe40loNbM2rz6HDv+xS4zZsQVQq6zazpZO3BpcCDK5/VVOmxOYk9UDFYdTa
 wg2gdI+CLHJYaF+iZsa9sbQzrK7H3TgXEG2Wpzkxg86uG8z+WG5YZgPgw/n3QI7iAJO7
 p9Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719033796; x=1719638596;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=;
 b=vzewzQbUp6EJfQKRSlCqr4FpLAyHzVxgFrw6uaYvMhmUCaar6E5sSFuNSHGln6DKxc
 kECKxtkY7eu8jFuvGRnjvOWr8qFaV4hbqOlld3Jv40YKfPqXH87rT65GOp6X+B0eOaur
 GQaFVhcZAzJAW3Iuw+1k23pmHux2A4dAvSN+leMd2uQxPnJ47hnvZ8TASQ1kH1HfE/TV
 x1GPPoOwcXz5+3aCMADM8eNDafF23GhwuisdgsfpQRoiLm0itWXzo7KsQIdjAuS2QRB6
 7y93OXyeKxtoChvmat+yX5TCpcIByT8W1x/fU5GXnrIAugnqJE7jo4AvXmxtKP9+CUjw
 o8SA==
X-Forwarded-Encrypted: i=1;
 AJvYcCXGGYONMZP+pYzWeH/yMY2RkYlgrD7Qj9ai9mnb8CdD5PWDqHXLizInPtC9Mg1kuv0+qXu9+MXcVOWDRYi31RaRMZHMDqk=
X-Gm-Message-State: AOJu0YzgyS9cM76e/q9NoVwweoSZiMK4CmpZ1c8K07mwK5X4vV+MPO0s
 RjgIwWkPJACUMdyRx6FGO+euaMCFaY+fNHQtE2GiZbtPysbVIjATbkv0kg==
X-Google-Smtp-Source: AGHT+IG2WVYKgEBKLBd7UdGSHNxjn/Q8Gi7fw2kh0YPXGKc8JzoK+TmqQk5w1wSPyrSrYiyvw7dlcA==
X-Received: by 2002:a17:906:a847:b0:a6f:e36:aba8 with SMTP id
 a640c23a62f3a-a6fab6488b8mr533431466b.33.1719033795681; 
 Fri, 21 Jun 2024 22:23:15 -0700 (PDT)
Received: from pro2.fritz.box (pd9e364bf.dip0.t-ipconnect.de.
 [217.227.100.191]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-a6fcf560746sm151406266b.156.2024.06.21.22.23.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 21 Jun 2024 22:23:15 -0700 (PDT)
From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
In-Reply-To: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's
 message of "Fri, 21 Jun 2024 16:53:04 -0400")
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
Date: Sat, 22 Jun 2024 07:23:14 +0200
Message-ID: <m2y16x4kl9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> writes:

> [ In retrospect I wish we'd stuck to the Emacs-20.1 design where
>   chars=3Dbytes.  I know it introduced a lot of breakage (and it'd be even
>   worse now), but it is The Right Thing=E2=84=A2 if you can ignore backwa=
rd
>   compatibility.  ]

(Wasn't that pre-20? I remember having a ton of problems with the "new"
redisplay when I ported it 19 to 20.)

+1

(And make character a type.)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 05:26:02 +0000
Resent-Message-ID: <handler.71644.B.171903393212787 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 71644 <at> debbugs.gnu.org
Cc: mitchellahren@HIDDEN, yantar92@HIDDEN, eliz@HIDDEN, monnier@HIDDEN
X-Debbugs-Original-To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-Debbugs-Original-Cc: Mitchell <mitchellahren@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by submit <at> debbugs.gnu.org id=B.171903393212787
          (code B ref -1); Sat, 22 Jun 2024 05:26:02 +0000
Received: (at submit) by debbugs.gnu.org; 22 Jun 2024 05:25:32 +0000
Received: from localhost ([127.0.0.1]:44136 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKtFk-0003K9-4K
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:25:32 -0400
Received: from lists.gnu.org ([209.51.188.17]:39310)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gerd.moellmann@HIDDEN>) id 1sKtFh-0003K1-Mz
 for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:25:30 -0400
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 <gerd.moellmann@HIDDEN>)
 id 1sKtDc-00043s-53
 for bug-gnu-emacs@HIDDEN; Sat, 22 Jun 2024 01:23:20 -0400
Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <gerd.moellmann@HIDDEN>)
 id 1sKtDa-00068y-HK; Sat, 22 Jun 2024 01:23:19 -0400
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a6fe118805dso28891166b.3; 
 Fri, 21 Jun 2024 22:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719033796; x=1719638596; darn=gnu.org;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=;
 b=IRdGOcjQPAFCZTAGglBcxaxB5M8POfjkv8Iv4/bALkU2/cYwzPvL0GYlzfTArAR/kJ
 Lw/hr1ujo/LObqkjIK446BteXllN3/b33czFfjo2wSIBr6Ujf+A5VY8puTHoHcA4r/84
 Jrcsp0F0foFYVmGY7bsuIE05ry5yaDcr30w8ScpHH1gucwZ7sGu/bELoFRyRNRt9S/qb
 tTMXVEOnpWkwWCJ4iDJMcDNzhM2kt4DYQOydjo6tJcGvZf5ezMozXG8q8Cwg+ypdyOib
 HS/i77PE0PqlA8jxFhk840JjZYhdiqgb7wTkaUXVN/wbdvfvuWhUoJJ+o0Bw1NxqIHQC
 mu3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719033796; x=1719638596;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=;
 b=e580+bSzuHkQUbPh210tuf3H7owvhSyOt4eqLg2KuYQnG5esJ66blNCPCugKgFKidj
 XKFN+ok9fGCOnlI0MLBOQHo6dcsW4ya+LwGgBh80ZKb0GqgXqjRwpNzOWXdxKpgmjjW8
 fOnCqLHs1RE5eNTRvVMO/mf4bZ9ZdODvxSS6J1SKYB8q9d1KN5vVtnr+GWn4wSf0DJBk
 lrTj+5vu4tZeFKMMtM5o3KKPBZV8+xjf3X39oPdvJyLm6BgSViTTUCkspyyQIxx4a2NB
 JSraKWI4qh7dBL3U23V439/Mhe6zbEREErVnE0hldNIRTpVMNqDd31j5aJiZO4/+DM+6
 Gzsg==
X-Forwarded-Encrypted: i=1;
 AJvYcCXADA3O+lu8DE9dcsC5AZI+ZZN766ygluszBY0N2ihD/mLUb18wk1LPU3YiiHt3qkSWQFLsoL4+IltmE18=
X-Gm-Message-State: AOJu0Yzfyi4qWwVc4/Ds+lr2b+oqmmVXQTcamBLqAb4zcXx8VSE5dGEd
 CZANSP1TzmIUw09M1o/CjxJ2Ng2wbgvm3VQQZ94pP+2DLgLH2Ld1cVSZIQ==
X-Google-Smtp-Source: AGHT+IG2WVYKgEBKLBd7UdGSHNxjn/Q8Gi7fw2kh0YPXGKc8JzoK+TmqQk5w1wSPyrSrYiyvw7dlcA==
X-Received: by 2002:a17:906:a847:b0:a6f:e36:aba8 with SMTP id
 a640c23a62f3a-a6fab6488b8mr533431466b.33.1719033795681; 
 Fri, 21 Jun 2024 22:23:15 -0700 (PDT)
Received: from pro2.fritz.box (pd9e364bf.dip0.t-ipconnect.de.
 [217.227.100.191]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-a6fcf560746sm151406266b.156.2024.06.21.22.23.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 21 Jun 2024 22:23:15 -0700 (PDT)
From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
In-Reply-To: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's
 message of "Fri, 21 Jun 2024 16:53:04 -0400")
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
Date: Sat, 22 Jun 2024 07:23:14 +0200
Message-ID: <m2y16x4kl9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::62d;
 envelope-from=gerd.moellmann@HIDDEN; helo=mail-ej1-x62d.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> writes:

> [ In retrospect I wish we'd stuck to the Emacs-20.1 design where
>   chars=3Dbytes.  I know it introduced a lot of breakage (and it'd be even
>   worse now), but it is The Right Thing=E2=84=A2 if you can ignore backwa=
rd
>   compatibility.  ]

(Wasn't that pre-20? I remember having a ton of problems with the "new"
redisplay when I ported it 19 to 20.)

+1

(And make character a type.)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 06:59:01 +0000
Resent-Message-ID: <handler.71644.B71644.171903948921281 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171903948921281
          (code B ref 71644); Sat, 22 Jun 2024 06:59:01 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 06:58:09 +0000
Received: from localhost ([127.0.0.1]:44180 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sKuhM-0005XB-H1
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 02:58:08 -0400
Received: from eggs.gnu.org ([209.51.188.92]:52704)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sKuhJ-0005We-Fp
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 02:58:07 -0400
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 <eliz@HIDDEN>)
 id 1sKuhC-0004Zq-Lt; Sat, 22 Jun 2024 02:57:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=Dd3ewHRw01Kgt0A14C9OVmJsgI9Bv1UTFTDpw48S3c4=; b=mrE7JfhO0/Yl
 dvFfNYXBVBvShnPv8grhRW/ZhtlZ2FMIyffa3iIWZAMUZxCqLtZR51pFuRKDd+PumdMaoE3ceoBVG
 GlH5Gdhnp/nDpSjxoAwd4tV39YRolrF3QYqxX366DTUeLM4qLy8T6cRQhs8IEUJg/uBWlgojlVoDs
 e6PPoFFlRGS0AwGczaR7vfNI2fIRnTnCgrUeLnFDRf8eCL4wTWE06y8SZ1dVv0LckTHfEdw3vUkbp
 hMgFRInT2J8D5X3yqM97X5+l5CSjqOSRZNaqIyHnrcM2kRJH3mEBbdIliz6eo7L6jmxpL21FZCk/M
 ydm0ZPZKwEnsMcTshEcloQ==;
Date: Sat, 22 Jun 2024 09:57:55 +0300
Message-Id: <86ed8pjwgc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv5xu210i4.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Fri, 21 Jun 2024 17:06:31 -0400)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Mitchell <mitchellahren@HIDDEN>,  71644 <at> debbugs.gnu.org
> Date: Fri, 21 Jun 2024 17:06:31 -0400
> 
> >   commit 8783700b23e70874c4996908bf02c010ae6f3fe1
> >   Author:     Stefan Monnier <monnier@HIDDEN>
> >   AuthorDate: Tue Aug 2 10:38:53 2022 -0400
> >   Commit:     Stefan Monnier <monnier@HIDDEN>
> >   CommitDate: Tue Aug 2 13:06:51 2022 -0400
> >
> >       * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1
> >
> > It changed the comparison operator in two places in marker.c.
> >
> > Curiously, the log message doesn't even mention the change in
> > marker.c, which could be a sign that this change was not intended to
> > be installed.  Stefan, did you intend to install it, and if so, do you
> > have any comments about this bug report?
> 
> Hmm... can't remember why/how it ended up in the above commit.
> Looks like an oversight.  But the change should be harmless: the
> `eassert` should make sure that the comparison gives the same answer
> either way (and AFAICT if/when the new comparison gives a different
> answer from the old code, the old code will loop until it segfaults).

Mitchell, can you try reverting that change, and see if that affects
performance in your case?

> > I'm a bit confused by the fact that I don't see the slowdown on my
> > machine, but maybe there are other factors at work here that hide
> > the regression.
> 
> The byte<->char conversion code is affected by many unrelated moving
> parts, so it can be difficult to come up with a reproducible recipe.

But in this case, we did that in "emacs -Q" and with a specific test
file that was posted and used.  What other variables can affect this
recipe?  Do you see the slow response on your machine, for example,
when running this recipe?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 13:52:02 +0000
Resent-Message-ID: <handler.71644.B71644.171906429621676 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Mitchell <mitchellahren@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171906429621676
          (code B ref 71644); Sat, 22 Jun 2024 13:52:02 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 13:51:36 +0000
Received: from localhost ([127.0.0.1]:44729 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL19T-0005dX-RL
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 09:51:36 -0400
Received: from mout01.posteo.de ([185.67.36.65]:39069)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sL19Q-0005dJ-TP
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 09:51:34 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id A6363240028
 for <71644 <at> debbugs.gnu.org>; Sat, 22 Jun 2024 15:51:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1719064286; bh=erPcSXhgVcXCneKH2EUCq/sjaHsU6I/cLv3uUf4Kkfo=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=pWgEb7XG2zNqFmxNQ24eWhdDS3B6GGs2TDkxZpKWS+9MHz3fEoDeiS19fCd63KOLW
 l4U2TvjKCNbd/ONmUCeW6Yv4Pwnpx6P7IlQuEqnxJJeoLImRN2Fly8NC6Z+74Tmx0I
 nX6nGwG/Gwjb5E4rM1JqNqYseu7DY//aaGRONoGhBPYC2PT2Ejs7/Z/wyHGrFb+w/y
 EKkOY1qNBfml2hiX69F7gLiLen3kxznpPvEtW3jKsvWBbcRyMxw54406CkA1m/dPs+
 FuSiZ4ZQGNS39vxLD5OaAMEgJX2F3nIwpO5wCflWbXMVxwOtnt9az8ca9hgQQbbwdN
 0C6sVxFb4VZjQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W5wcY1PyQz9rxD;
 Sat, 22 Jun 2024 15:51:25 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
Date: Sat, 22 Jun 2024 13:53:08 +0000
Message-ID: <87zfrdgk3f.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Mitchell <mitchellahren@HIDDEN> writes:

> Here are the steps to reproduce the issue:
> ...

For the record, I am able to reproduce the problem using the latest
Emacs master.

And the problem does disappear with my patch that affects the marker
loop in src/marker.c (buf_bytepos_to_charpos)

So, markers appear to be the culprit on my system.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 14:09:02 +0000
Resent-Message-ID: <handler.71644.B71644.171906532925614 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171906532925614
          (code B ref 71644); Sat, 22 Jun 2024 14:09:02 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 14:08:49 +0000
Received: from localhost ([127.0.0.1]:47232 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL1Q8-0006f3-VF
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:08:49 -0400
Received: from mout02.posteo.de ([185.67.36.66]:49711)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sL1Q6-0006el-Jd
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:08:47 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id C00AF240103
 for <71644 <at> debbugs.gnu.org>; Sat, 22 Jun 2024 16:08:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1719065320; bh=NEYDy0q8Al0jhoD5qSbKSfnt4hRb/+sUDIOO8tlMKhU=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=ikyN5m5WUUg2qMmUNSXy3Gb3ElY2daBB2DEsktxM+ZeP41f86JzxMI9vl466GTXjX
 /VVREveM6bcR8WIfhH1tImbzy3htNt2YNrrqF2T7d5WNrjcyoYEjoel5mXXQxWb9pu
 2zLXALYGLa0d0jIyL+jZ+ljokXyJoLf12IzD72we1LMm84Y7l8sjL9m43nmfSgQD5y
 FTiNeDQ9fHvCCBka6xWUwOz7W74ituXbd+xdo51oT8FjNA0qC3B2PCHvCmR786k3+C
 MdCW6et53ra7vt7f0b2ITsx27U2TDLDlpIfsQLOSxWL7zc+TnRLtwSeXTJy+W+Qik8
 1eBgZ2Ih5ggCA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W5x0S07LJz6tyX;
 Sat, 22 Jun 2024 16:08:39 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
Date: Sat, 22 Jun 2024 14:10:23 +0000
Message-ID: <87wmmhgjao.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

>> I got 5x `re-search-forward' speed improvement in my setup with this
>> dumb change.
>
> Hmm... of course, there'd likely be other circumstances where it would
> make it 5x slower.  E.g. in a large buffer, doing a forward search from
> the middle of the buffer when the first 50 markers happen to all be near
> the beginning of the buffer will mean that we always use the "slow path"
> which scans all the bytes between PT and the position of interest to
> count the number of chars therein.

Yup. I _do not_ propose my patch to be merged.
(BTW, we should probably merge this bug and bug#63040 where I first
shared this patch - just to demonstrate the problem and discuss possible
solutions)

> BTW, we already stop after at most N/50 markers where N is the smallest
> distance between the position of interest and point/bob/eob/gap (oh and
> the position of the last conversion).  So it seems that in your test,
> this distance N is >2500.  Also when that distance is >5000 we create
> a new marker, so next time around that position should be at the
> beginning of the marker-list.  So I wonder what happens in your test:
> why do we jump "very far" (more than 2500) between each call to the
> conversion function?  Also, maybe we should increase
> BYTECHAR_DISTANCE_INCREMENT?  ]

It is indeed another option.
Also, from bug#63040

    Another idea could be moving the cache markers into a separate
    array, so that we can examine them without mixing with all other
    buffer markers.

> Using markers as a cheap cache of conversions was a cute hack but we
> really need to replace it.
>
> Some options that come to mind:
>
> - Keep the tradition of abusing an existing data structure, and stash
>   the bytepos info inside the overlay tree or the text properties.
>   This way the conversion is bounded by O(log BUFFERSIZE).

For overlay tree, it might be even better to stash all the markers in
Emacs into itree structure. For now, every operation involving
adjusting/searching markers scales linearly - not ideal.

> - Use a dedicated data-structure.  E.g. a pair of array-with-a-gap
>   (one indexed by BYTEPOS/STEP the other indexed by CHARPOS/STEP, where
>   STEP would be a large enough constant to make those arrays cheap yet
>   small enough that the remaining scan is cheap).
>   This way the conversion is O(STEP), i.e. "constant-time".

I think that it will be less efficient compared to using a tree-like
structure (if we can manage to use it). Will it be easier?

> BTW, among my various local hacks, I've been using the hack below, which
> aims to randomize the order in our markers-list, so as to minimize the
> risk that we have to wade through lots of markers all clumped around the
> same position.  I don't think it does a good job of it, but maybe we can
> improve the execution of this idea, tho it still doesn't help if there's
> no GC involved.

I am not sure if I believe that this approach can yield practical gains.
AFAIU, the problem with the slowdown we are discussing here is markers
that are all around the same position. It's rather too many markers in
general, spaced not far from each other.

> BTW, if/when we use some other data-structure to convert bytes<->chars,
> then we could presumably get rid of our markers-list and stash markers
> inside our overlay tree (basically represent them as degenerate overlays
> with beg==end and no properties).

I am wondering why it is impossible to stash markers inside overlay tree
without doing anything special about bytes<->chars conversion (other
than changing the linear loop with itree query).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 14:13:02 +0000
Resent-Message-ID: <handler.71644.B71644.171906558126126 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171906558126126
          (code B ref 71644); Sat, 22 Jun 2024 14:13:02 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 14:13:01 +0000
Received: from localhost ([127.0.0.1]:47362 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL1UC-0006nK-So
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:13:01 -0400
Received: from eggs.gnu.org ([209.51.188.92]:60506)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sL1UA-0006my-4F
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:12:59 -0400
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 <eliz@HIDDEN>)
 id 1sL1U4-0005M8-4V; Sat, 22 Jun 2024 10:12:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=mmU3Hqlq3zYUZenhbQ8yjLn/cpy9S2tFJRXPQ6Wk14Y=; b=g3W7SNUh9zQ/
 6q/oXO2LvdGoNwv0NlNDkfOzMiS8x2CfVnIOVGLzQPB2qUPr7sXLEUaCK7lgEcAemLjeHKk8HB+h0
 rTv1ENxEV63vTo5myLvX2uqsW1RgoB2wA0leNSFKsIcqTZmR7xkrwYM60haiLaYxTH89KtvI7ZZ7o
 rzG7Y0pjOw8ZDmU4a/mviB4yGa/PyZtv5LtdXEF6FEvRkblPgi4cyZaHSyXfRlhpixzwiq/j7b1Qn
 9mc36v860U5+kAheu7858ThOUYcpukpkTIpkZKTOGdJUAF+fs+AGB2bxk4NLEuF1oSeBd2YlF4DIX
 XQnQDnKZwUgDe8ZmnvK25Q==;
Date: Sat, 22 Jun 2024 17:12:47 +0300
Message-Id: <86iky1gj6o.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87zfrdgk3f.fsf@localhost> (message from Ihor Radchenko on Sat,
 22 Jun 2024 13:53:08 +0000)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <87zfrdgk3f.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 71644 <at> debbugs.gnu.org
> From: Ihor Radchenko <yantar92@HIDDEN>
> Date: Sat, 22 Jun 2024 13:53:08 +0000
> 
> Mitchell <mitchellahren@HIDDEN> writes:
> 
> > Here are the steps to reproduce the issue:
> > ...
> 
> For the record, I am able to reproduce the problem using the latest
> Emacs master.
> 
> And the problem does disappear with my patch that affects the marker
> loop in src/marker.c (buf_bytepos_to_charpos)
> 
> So, markers appear to be the culprit on my system.

Not the markers, but conversion of character positions to buffer
positions.  Which uses markers, but that's an implementation detail...

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 14:16:02 +0000
Resent-Message-ID: <handler.71644.B71644.171906575926554 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: yantar92@HIDDEN, mitchellahren@HIDDEN
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171906575926554
          (code B ref 71644); Sat, 22 Jun 2024 14:16:02 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 14:15:59 +0000
Received: from localhost ([127.0.0.1]:47482 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL1X5-0006uC-Dn
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:15:59 -0400
Received: from eggs.gnu.org ([209.51.188.92]:51940)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sL1X3-0006tn-Kx
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:15:58 -0400
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 <eliz@HIDDEN>)
 id 1sL1Wv-0006HL-Fg; Sat, 22 Jun 2024 10:15:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=PN9MRAFHiY25yVlwNGaCNJKItmJBwcFAav0ByvP94hc=; b=lIFhdvhebOeP
 OlQE3Gsv7iesWy8rYSBG6Xpl/D3j/aBds0xOQBDitK23+wD83bXrEsGEVMFn+WoA8wmjgNc003kLU
 PRYzTYIZrx/Ma+40UiE9kfecKLzFtSTJ/Jttpk95q2ohCQFsMilLXRa9ChyvP2D7fRbk4uBkixeBO
 xWE8f1gwjAmfz/EB/I8txtRILzbtZ/v2QayQyaGpOIJxIxE2C4tk3LnXZWZgzjW+5a3rMv/I0fksw
 V+zi8v1Ean8+HVuxEuidqpE+Dg/gBTMKswdKJukTaxBvETwlmU33f86ILzZxngmBcPEeIiXifVdcz
 h05iMN6DY45j4Dkn6y3zWA==;
Date: Sat, 22 Jun 2024 17:15:46 +0300
Message-Id: <86h6dlgj1p.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <86iky1gj6o.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 22
 Jun 2024 17:12:47 +0300)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <87zfrdgk3f.fsf@localhost> <86iky1gj6o.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
> Date: Sat, 22 Jun 2024 17:12:47 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> Not the markers, but conversion of character positions to buffer
> positions.                                                ^^^^^^
  ^^^^^^^^^
Sorry, I meant byte positions, of course.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 15:10:01 +0000
Resent-Message-ID: <handler.71644.B71644.17190689791254 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Mitchell <mitchellahren@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17190689791254
          (code B ref 71644); Sat, 22 Jun 2024 15:10:01 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 15:09:39 +0000
Received: from localhost ([127.0.0.1]:49250 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL2N0-0000K7-Bh
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:09:39 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6582)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sL2My-0000Jl-3Q
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:09:36 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 92DB044418E;
 Sat, 22 Jun 2024 11:09:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719068966;
 bh=mzaljtl/ikyK/fIuitP1Hqoy+cyA7gBxNYHTf2bGS7I=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=VtYvXBvvLtxUxyB59TFqhptVJD9U+mYLz4SqmbrE2cRLSRgZoYmeG5PcfDwt/jWE4
 ZPmFxNJ6/BDrPGGm1dnsmJp+R5rFMN2pu570LB8wU4eCEoOwQQnkCaPJ93/niDbO4h
 0O5ApGMdQ3MW4RhIbYkk4V5iABEa+xgMeZVC4fGgYfRkfwC2+Ffrqfe3no8rCeX3hN
 mBmDdb7YSImONGum5QFDvnCMZeJULqpCWw6H0UaH2tGz1h2ug+nng8okO+9TmQFhou
 UFBcMfH31JHc1WvPkAhn/Wtc0DON4oLyzA14Qcmo7rNcAj4ZUwBjHFHeSZm5rTaBZV
 nzeJ8EbnlFAYw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A46EA442179;
 Sat, 22 Jun 2024 11:09:26 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 78A8F12022C;
 Sat, 22 Jun 2024 11:09:26 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 (Mitchell's message of "Tue, 18 Jun 2024 23:25:18 -0600")
Message-ID: <jwvmsnd6o75.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
Date: Sat, 22 Jun 2024 11:09:25 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.115 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> 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).

I used the code below:

    (customize-set-variable 'large-file-warning-threshold nil)
    (package-install 'counsel)
    (package-activate 'counsel)

> 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 minim=
al
> config above) to show up on the screen.

Without running `counsel-outline`, the insertion is "immediate", whereas
after `counsel-outline` it takes about two seconds for me.

> 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 big=
 entry for
> `redisplay_internal (C function)`.

[ I haven't been able to get a meaningful profiler report yet.
  E.g. I get 82% of the time given to `read-from-minibuffer`, which is
  presumably the time spent typing `M-x profiler-report RET` or some
  such, even though I typed enough `n SPC` repetitions that it should
  dwarf that.  Not sure what's going on.  ]

Also I notice that if I do `n` and then wait, it takes the same
amount of time to see the result as if I do `n n n n`
and then wait.  So it seems that the command themselves execute
"instantly", and the delay occurs later (jit-lock? redisplay? ...).

I also notice that step 6 is important: if I just go straight to line 35
and type text, there's no delay.
Other thing I noticed

   M-g M-g 60000 RET
   n n n n n
   M-g M-g 35 RET
   n n n n n

there's no delays typing the `n` at line 60000 but there is a 2s delay
at line 35.

The fact that the absence of non-ASCII chars eliminates the problem
strongly points the finger to the bytes<->chars conversion which relies
on markers, indeed, but it's still very puzzling: line 35 is about 1.5kB
from the beginning of the buffer, so the conversion should be simple
and fast. there.  IOW, if it's a slow bytes<->chars conversion it's
probably a conversion taking place elsewhere than near point.

AFAICT the most significant change w.r.t markers in Emacs-29 is that
markers aren't used internally for overlays any more, so there are
usually *fewer* markers in Emacs-29 buffers than in Emacs-28 buffers
(which can be both favorable and detrimental to bytes<->chars
conversion, depending on details).  But in any case, (overlays-in
(point-min) (point-max)) tells me there's only one overlay and even 0 in
Emacs-28, so that can't be the reason for the change.


        Stefan "puzzled"

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 15:53:01 +0000
Resent-Message-ID: <handler.71644.B71644.17190715457752 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17190715457752
          (code B ref 71644); Sat, 22 Jun 2024 15:53:01 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 15:52:25 +0000
Received: from localhost ([127.0.0.1]:50501 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL32O-00020v-Mb
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:52:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25732)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sL32N-00020Z-0C
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:52:23 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9B57044212F;
 Sat, 22 Jun 2024 11:52:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719071529;
 bh=kbWq6dpFJMeDg6qGg+/mtp3lRgzdIGAsP5qKqA0T8x4=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=WDZTMO4tqDHkA7ONe4BPB5v0jfrNAumjvs+wu58Gxv59jWjMKjbQAvyCpzS/mTun0
 lTmLro3jTZmxAaFMVXQ27wG546KTFe1zKbXxKzovLZexnjTNU05J3uPF+8gBowwNnw
 3GBiUbMwLqA3eB72Vq5NhF5aq9Zyf69RynLBjIcnSPyTAjhkkoeTscYCia8KUayWjv
 EmYWOAlAdsbgrkx9T/K5WA5Reaot+m1tWsJJXGui6d2CCyl5/VthGv8TopSDuLVlOO
 V2/jPYM5lB8Pca2786/lL48TZMqdA0kvVAe5nM3XOGRMPMxi47Ri8u4ghtLmYNsGNZ
 BmIsvvWFxVpLA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5866D4420EF;
 Sat, 22 Jun 2024 11:52:09 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 23F45120828;
 Sat, 22 Jun 2024 11:52:09 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87wmmhgjao.fsf@localhost> (Ihor Radchenko's message of "Sat, 22
 Jun 2024 14:10:23 +0000")
Message-ID: <jwvbk3t6lu4.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost>
Date: Sat, 22 Jun 2024 11:52:08 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.113 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> (BTW, we should probably merge this bug and bug#63040 where I first
> shared this patch - just to demonstrate the problem and discuss possible
> solutions)

Ah, thanks, I'll take a look at that bug.

>     Another idea could be moving the cache markers into a separate
>     array, so that we can examine them without mixing with all other
>     buffer markers.

=F0=9F=99=82

>> Using markers as a cheap cache of conversions was a cute hack but we
>> really need to replace it.
>>
>> Some options that come to mind:
>>
>> - Keep the tradition of abusing an existing data structure, and stash
>>   the bytepos info inside the overlay tree or the text properties.
>>   This way the conversion is bounded by O(log BUFFERSIZE).
>
> For overlay tree, it might be even better to stash all the markers in
> Emacs into itree structure.

Yes, I don't really distinguish the itree structure and the overlay
tree, but indeed we could have a separate itree for the markers.

> For now, every operation involving
> adjusting/searching markers scales linearly - not ideal.

Adjusting only happens upon insertion, and while it's definitely not
ideal, it's surprising how little it bites in practice.
And if we move to an array-with-gap it'll bite even much less.

As for searching markers, AFAIK the only time we do that is for ....
.... the bytes<->chars conversion =F0=9F=99=82

[ Admittedly, we also do a search when we delete a marker, but that'd be
  easy to optimize away in the common case if we cared about it.  ]

IIRC, XEmacs doesn't use a linked-list of markers but an array-with-gap
of markers instead.  Not sure if they keep it sorted, but if they do, such
an array-with-gap can even be binary-searched, so it's quite efficient.

>> - Use a dedicated data-structure.  E.g. a pair of array-with-a-gap
>>   (one indexed by BYTEPOS/STEP the other indexed by CHARPOS/STEP, where
>>   STEP would be a large enough constant to make those arrays cheap yet
>>   small enough that the remaining scan is cheap).
>>   This way the conversion is O(STEP), i.e. "constant-time".
> I think that it will be less efficient compared to using a tree-like
> structure (if we can manage to use it). Will it be easier?

Given we've survived with a *really* poor data-structure until now,
I suspect that we don't need to worry about choosing the most efficient
option. =F0=9F=99=82

>> BTW, among my various local hacks, I've been using the hack below, which
>> aims to randomize the order in our markers-list, so as to minimize the
>> risk that we have to wade through lots of markers all clumped around the
>> same position.  I don't think it does a good job of it, but maybe we can
>> improve the execution of this idea, tho it still doesn't help if there's
>> no GC involved.
> I am not sure if I believe that this approach can yield practical gains.

Neither am I.  Another idea I had in the same vicinity (and hence
arguably just as unconvincing) was that in buf_*pos_to_*pos, when we
exit the

    for (tail =3D BUF_MARKERS (b); tail; tail =3D tail->next)

loop, we could move the markers we just skipped to the end of the list,
based on the idea that we've just found them to be useless at the head.
Doing it efficiently requires keeping a pointer to the end of the list, tho.

> AFAIU, the problem with the slowdown we are discussing here is markers
> that are all around the same position. It's rather too many markers in
> general, spaced not far from each other.

Sounds about right.  But if we could keep them nicely randomized (which
was my original goal with my quick hack), then the total number of
markers wouldn't matter that much because the first N markers in the
list would still be (probabilistically) nicely spread over the
whole buffer.

>> BTW, if/when we use some other data-structure to convert bytes<->chars,
>> then we could presumably get rid of our markers-list and stash markers
>> inside our overlay tree (basically represent them as degenerate overlays
>> with beg=3D=3Dend and no properties).
> I am wondering why it is impossible to stash markers inside overlay tree
> without doing anything special about bytes<->chars conversion (other
> than changing the linear loop with itree query).

I think the answer is that it's not not possible.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Mitchell <mitchellahren@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 18:05:01 +0000
Resent-Message-ID: <handler.71644.B71644.171907949126216 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171907949126216
          (code B ref 71644); Sat, 22 Jun 2024 18:05:01 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 18:04:51 +0000
Received: from localhost ([127.0.0.1]:54946 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL56Y-0006oj-Lx
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:04:51 -0400
Received: from mail-ed1-f51.google.com ([209.85.208.51]:50687)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mitchellahren@HIDDEN>) id 1sL56W-0006oM-L8
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:04:49 -0400
Received: by mail-ed1-f51.google.com with SMTP id
 4fb4d7f45d1cf-57cb9a370ddso3408778a12.1
 for <71644 <at> debbugs.gnu.org>; Sat, 22 Jun 2024 11:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719079423; x=1719684223; 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=su6aDWKFkbQ8+hu0mQki+XFaWw+x3OMrKWBvARUph0E=;
 b=Bhoays4B6HZupUdsrkfWjPvcF+WmrpF6urmW8RILAur3i7tqOHU27djF17ZOOWDRzC
 I02UWr+yYexrw+y5Q+P7EdVsDXvF6eqjXQvayeI5+fmzP56fgSjS7c4DkZANCSGlrIk+
 d6i1YJ6YBKBtysm9vTKKPX5wwp50Y/AtiHGN+4AEZzOIOasVmBBwJkpK5dzyXSrzqcqG
 fraOxcXe2f3JQOsEjQAYhTCavRM5d/W4AiQ/WPrVOxKWahA4VwtAaIkLJYLGPrztQWv4
 um+KDR/MCe92qtN5x46r8c1lvR41JKGyXJbzfKgVvhyc+DAi0Jm6Vtd9UfeVdZ1qAv5E
 ihrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719079423; x=1719684223;
 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=su6aDWKFkbQ8+hu0mQki+XFaWw+x3OMrKWBvARUph0E=;
 b=s7+mU4HoePgziln+cqtJsT/Gma8qCsLaIIAG4H8uwXzfJgkccdmH0n5R+7wnf/tQFU
 ztVp7X6K/hWcbn9gKnMo/Hjpgdckm1mOaZnZFM0R1Rvc9R/S7x2CnTnNE8DutWmGdE2Z
 n+c9/5sDS6tQ3rbXwUC6/69hJYK157HUxUM6LUS0tPY48XMpMihY8OPDCB5grDtvXO0v
 CbcWK6soYjAN9Vp8WBeB1bNm2/fcJbnhq3Y4zUTsIzSiojoaHkrAfTeTqS9s+IjT7M5o
 i6F1buW1cUCRenCrb4s1G69bZo1I0U0tJaBdMY5H6JA7PhhC2hos1YGPIHtj27vvdhHe
 eDmw==
X-Forwarded-Encrypted: i=1;
 AJvYcCWq7dZg4p683su2NLiuJarXFl4MST48AN6LMAQWZAe+eJ7cZN4mLwqXDstMQ+rDAko5bEyJA3H0K+c7uaQZ2JQfXZYdq/s=
X-Gm-Message-State: AOJu0Ywl2gfreP0VgN4jrFbRx8Il8ve2y1AqrjXHTDOxJh8h/lCf9aYN
 vwQdTIAKLwhf6Y1z39L8hu2SeRLaRTpnGiQI5obkDR9nnPHtjOsY9YszsegShE9bfFyC1GX7l6q
 JIA0fdz/fd+QcgYbQd/twDU9BF/o=
X-Google-Smtp-Source: AGHT+IF2OHdHNTh2KkH7ti1SD+yR80Zp0IUlRCxYJGdHjf2ozpPWtJMP+jT4/c7mjJ+8sRmsTPSG4DnI+ZJ9sZOAbN0=
X-Received: by 2002:a50:c04f:0:b0:57d:3791:e8e4 with SMTP id
 4fb4d7f45d1cf-57d4bdcad8dmr345923a12.32.1719079422529; Sat, 22 Jun 2024
 11:03:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
 <86ed8pjwgc.fsf@HIDDEN>
In-Reply-To: <86ed8pjwgc.fsf@HIDDEN>
From: Mitchell <mitchellahren@HIDDEN>
Date: Sat, 22 Jun 2024 12:03:05 -0600
Message-ID: <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000052192f061b7e5e3b"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000052192f061b7e5e3b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 22, 2024 at 12:58=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote=
:

> > > From: Stefan Monnier <monnier@HIDDEN>
> > > Cc: Mitchell <mitchellahren@HIDDEN>,  71644 <at> debbugs.gnu.org
> > > Date: Fri, 21 Jun 2024 17:06:31 -0400
> > >
> > > >   commit 8783700b23e70874c4996908bf02c010ae6f3fe1
> > > >   Author:     Stefan Monnier <monnier@HIDDEN>
> > > >   AuthorDate: Tue Aug 2 10:38:53 2022 -0400
> > > >   Commit:     Stefan Monnier <monnier@HIDDEN>
> > > >   CommitDate: Tue Aug 2 13:06:51 2022 -0400
> > > >
> > > >       * src/xdisp.c (redisplay_window): Use BEG rather than hard
> coding 1
> > > >
> > > > It changed the comparison operator in two places in marker.c.
> > > >
> > > > Curiously, the log message doesn't even mention the change in
> > > > marker.c, which could be a sign that this change was not intended t=
o
> > > > be installed.  Stefan, did you intend to install it, and if so, do
> you
> > > > have any comments about this bug report?
> > >
> > > Hmm... can't remember why/how it ended up in the above commit.
> > > Looks like an oversight.  But the change should be harmless: the
> > > `eassert` should make sure that the comparison gives the same answer
> > > either way (and AFAICT if/when the new comparison gives a different
> > > answer from the old code, the old code will loop until it segfaults).
> >
> > Mitchell, can you try reverting that change, and see if that affects
> > performance in your case?
>

Eli, after Ihor and Stefan were able to reproduce it now, would it still be
helpful for me to do this and report back? I=E2=80=99m more than happy to i=
f it
would help in any way.

Also should I be replying to the renamed thread from now on? (i.e.,
"chars=3D=3Dbytes (was: bug#71644: 30.0.50; Severe slowdown in larger files
with markers beginning in emacs 29+") This is my first bug report, so I=E2=
=80=99m
not sure the etiquette, haha.

--00000000000052192f061b7e5e3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Sat, Jun 22, 2024 at 12:58=E2=80=AFAM Eli Zaretskii &lt;<a href=
=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
&gt;=20

&gt; From: Stefan Monnier &lt;<a href=3D"mailto:monnier@HIDDEN" t=
arget=3D"_blank">monnier@HIDDEN</a>&gt;<br>
&gt;=20


&gt; Cc: Mitchell &lt;<a href=3D"mailto:mitchellahren@HIDDEN" target=3D"=
_blank">mitchellahren@HIDDEN</a>&gt;,=C2=A0 <a href=3D"mailto:71644@debb=
ugs.gnu.org" target=3D"_blank">71644 <at> debbugs.gnu.org</a><br>
&gt;=20


&gt; Date: Fri, 21 Jun 2024 17:06:31 -0400<br>
&gt;=20


&gt; <br>
&gt;=20


&gt; &gt;=C2=A0 =C2=A0commit 8783700b23e70874c4996908bf02c010ae6f3fe1<br>
&gt;=20


&gt; &gt;=C2=A0 =C2=A0Author:=C2=A0 =C2=A0 =C2=A0Stefan Monnier &lt;<a href=
=3D"mailto:monnier@HIDDEN" target=3D"_blank">monnier@HIDDEN=
l.ca</a>&gt;<br>
&gt;=20


&gt; &gt;=C2=A0 =C2=A0AuthorDate: Tue Aug 2 10:38:53 2022 -0400<br>
&gt;=20


&gt; &gt;=C2=A0 =C2=A0Commit:=C2=A0 =C2=A0 =C2=A0Stefan Monnier &lt;<a href=
=3D"mailto:monnier@HIDDEN" target=3D"_blank">monnier@HIDDEN=
l.ca</a>&gt;<br>
&gt;=20


&gt; &gt;=C2=A0 =C2=A0CommitDate: Tue Aug 2 13:06:51 2022 -0400<br>
&gt;=20


&gt; &gt;<br>
&gt;=20


&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0* src/xdisp.c (redisplay_window): Use B=
EG rather than hard coding 1<br>
&gt;=20


&gt; &gt;<br>
&gt;=20


&gt; &gt; It changed the comparison operator in two places in marker.c.<br>
&gt;=20


&gt; &gt;<br>
&gt;=20


&gt; &gt; Curiously, the log message doesn&#39;t even mention the change in=
<br>
&gt;=20


&gt; &gt; marker.c, which could be a sign that this change was not intended=
 to<br>
&gt;=20


&gt; &gt; be installed.=C2=A0 Stefan, did you intend to install it, and if =
so, do you<br>
&gt;=20


&gt; &gt; have any comments about this bug report?<br>
&gt;=20


&gt; <br>
&gt;=20


&gt; Hmm... can&#39;t remember why/how it ended up in the above commit.<br>
&gt;=20


&gt; Looks like an oversight.=C2=A0 But the change should be harmless: the<=
br>
&gt;=20


&gt; `eassert` should make sure that the comparison gives the same answer<b=
r>
&gt;=20


&gt; either way (and AFAICT if/when the new comparison gives a different<br=
>
&gt;=20


&gt; answer from the old code, the old code will loop until it segfaults).<=
br>
&gt;=20


<br>
&gt;=20


Mitchell, can you try reverting that change, and see if that affects<br>
&gt;=20


performance in your case?<br></div></blockquote><div><br>
</div><div>Eli, after Ihor and Stefan were able to reproduce it now, would =
it still
 be helpful for me to do this and report back? I=E2=80=99m more than happy =
to=20
if it would help in any way. <br></div><div><br></div><div>Also should I be=
 replying to the renamed thread from now on? (i.e., &quot;chars=3D=3Dbytes =
(was: bug#71644: 30.0.50; Severe slowdown in larger files with markers begi=
nning in emacs 29+&quot;) This is my first bug report, so I=E2=80=99m not s=
ure the etiquette, haha.<br></div><div>=C2=A0</div></div></div>

--00000000000052192f061b7e5e3b--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 22 Jun 2024 18:18:02 +0000
Resent-Message-ID: <handler.71644.B71644.171908026627943 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Mitchell <mitchellahren@HIDDEN>
Cc: monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171908026627943
          (code B ref 71644); Sat, 22 Jun 2024 18:18:02 +0000
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 18:17:46 +0000
Received: from localhost ([127.0.0.1]:55381 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sL5J4-0007Gb-Cy
	for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:17:46 -0400
Received: from eggs.gnu.org ([209.51.188.92]:44822)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sL5J2-0007GN-AB
 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:17:44 -0400
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 <eliz@HIDDEN>)
 id 1sL5Iw-000299-S6; Sat, 22 Jun 2024 14:17:38 -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=zyqRqHqywKk9x2n1qcTUtLefRiYgAdhsul7bpXdXR8o=; b=eH66Q80NKkfA/u9wHBBK
 GbJADyy188Ac1ZuxwkZH6KLJgyI8cZm2j7CXjKQF+WfqT2ja54DwIVx6UjvvuSmkEHjJTkaqpzn8n
 xo8YCSE0WA44nopSztaaedtucdAtRVFlxuOe7beYZ+sASemqEUNAZZtoMbSIp/RCXgHIHikMCfJoH
 vvoGRBObzqTZmJCNZdeUq24h+gPUt2z47TlyJFIu0N1crwYE0bC1YY42peQ4hxHlOF8fHZbHC19KP
 IMrj1S2wztiqhy8dOmS3xayH3alTqknmkhOVv0WxuHBo0/lqZuaLjEJQATAPB3cvknhMGv5DAB3m/
 pXuERQ+hwRqXbQ==;
Date: Sat, 22 Jun 2024 21:17:36 +0300
Message-Id: <86wmmgg7un.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
 (message from Mitchell on Sat, 22 Jun 2024 12:03:05 -0600)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
 <86ed8pjwgc.fsf@HIDDEN>
 <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Mitchell <mitchellahren@HIDDEN>
> Date: Sat, 22 Jun 2024 12:03:05 -0600
> Cc: Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org
> 
> On Sat, Jun 22, 2024 at 12:58 AM Eli Zaretskii <eliz@HIDDEN> wrote:
> 
>  > > From: Stefan Monnier <monnier@HIDDEN>
>  > > Cc: Mitchell <mitchellahren@HIDDEN>,  71644 <at> debbugs.gnu.org
>  > > Date: Fri, 21 Jun 2024 17:06:31 -0400
>  > > 
>  > > >   commit 8783700b23e70874c4996908bf02c010ae6f3fe1
>  > > >   Author:     Stefan Monnier <monnier@HIDDEN>
>  > > >   AuthorDate: Tue Aug 2 10:38:53 2022 -0400
>  > > >   Commit:     Stefan Monnier <monnier@HIDDEN>
>  > > >   CommitDate: Tue Aug 2 13:06:51 2022 -0400
>  > > >
>  > > >       * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1
>  > > >
>  > > > It changed the comparison operator in two places in marker.c.
>  > > >
>  > > > Curiously, the log message doesn't even mention the change in
>  > > > marker.c, which could be a sign that this change was not intended to
>  > > > be installed.  Stefan, did you intend to install it, and if so, do you
>  > > > have any comments about this bug report?
>  > > 
>  > > Hmm... can't remember why/how it ended up in the above commit.
>  > > Looks like an oversight.  But the change should be harmless: the
>  > > `eassert` should make sure that the comparison gives the same answer
>  > > either way (and AFAICT if/when the new comparison gives a different
>  > > answer from the old code, the old code will loop until it segfaults).
>  > 
>  > Mitchell, can you try reverting that change, and see if that affects
>  > performance in your case?
> 
> Eli, after Ihor and Stefan were able to reproduce it now, would it still be helpful for me to do this and report
> back? I’m more than happy to if it would help in any way. 

Yes, because we still don't understand well why performance regressed
from Emacs 28 to Emacs 29.

> Also should I be replying to the renamed thread from now on? (i.e., "chars==bytes (was: bug#71644: 30.0.50;
> Severe slowdown in larger files with markers beginning in emacs 29+") This is my first bug report, so I’m not
> sure the etiquette, haha.

No, please keep replying with the original Subject.  That other thread
was a side issue.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Mitchell <mitchellahren@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 24 Jun 2024 07:12:02 +0000
Resent-Message-ID: <handler.71644.B71644.17192130783660 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17192130783660
          (code B ref 71644); Mon, 24 Jun 2024 07:12:02 +0000
Received: (at 71644) by debbugs.gnu.org; 24 Jun 2024 07:11:18 +0000
Received: from localhost ([127.0.0.1]:43440 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sLdrB-0000wy-Ms
	for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 03:11:18 -0400
Received: from mail-ed1-f50.google.com ([209.85.208.50]:49198)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mitchellahren@HIDDEN>) id 1sLdr8-0000wh-0f
 for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 03:11:15 -0400
Received: by mail-ed1-f50.google.com with SMTP id
 4fb4d7f45d1cf-57d331cc9feso1920843a12.2
 for <71644 <at> debbugs.gnu.org>; Mon, 24 Jun 2024 00:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719213007; x=1719817807; 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=8p2nwWUC5Pl56S26kG3wVnRsAREcVHm63OpBNtR8AbU=;
 b=Y0E+JcQLuKp+riiAud0e/7shUVq7ii3GtLswskmOv5JmTP221HH43sE7JJA0A90lev
 ZnM4k/nsWKInVxhE6yS0yY85Bho5d5txSfdDUBXiOE9KcgnI2RjIvjCnv61ITW6ZAPk5
 WMKU8MAY96R70UFTAIoQf3LCFxL/fGQ57mSpNHq6Oac6H2U4KyGaYb6g173pvfkQc9bY
 BigSp2UP5/nRbXcSiC7aoRHge6vPCag6CH6Xwc0k52yelSKaSJ3SvrZJl8i7ttpbgsqi
 NwoRhNmApbVwGislavXd4LP1lWPCYlK7YXXL/e9GET+3OBOaMht3cn5Yy3E2Gqgiiy9P
 wbFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719213007; x=1719817807;
 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=8p2nwWUC5Pl56S26kG3wVnRsAREcVHm63OpBNtR8AbU=;
 b=JmWDJIYOhLweAOv2Rv73U3jBW4W46aZ7o1p8DHVwHIYULq1pquaJoqxh5VDezSI+Ip
 l126SOj14+VER2+jZCYqvuF0XS//DzXirNN5bhm8B082zDLPj1eLrs2OcYnmnl9Z5owR
 EGc5GH65T1xTdbB2Qb2rgVtnPznI3NTn4XcFtjRGNCHVX7lYcStg+iXrelurSH1hb12r
 2hIhPemAb8Oot6gVLTODZiGg3Q8/hqV8ZHWqvKye2eyJh6Yu3c2ILDMvlTCFrH05Yogm
 CFZ59O3X5xQJkUspnR6yUnXlZh+ndDwRzMsoo7FVz7JixaaCM1W6exqdyT1SEP+J4UJB
 LLuw==
X-Forwarded-Encrypted: i=1;
 AJvYcCWHEwEx+d8wa/R7GX6H3rxHzjLSjvM50XNp5fu+TSW4AClDQIlHxYgCfiA0EB5PQWcReb5VEoViyh14lLF4sYFtM+szMaI=
X-Gm-Message-State: AOJu0YxhuY0IksuDJYKWi+Eh4pV6nbUgi+CBbsMlkNm/Ns5AitNMDzbI
 skv5Fysc5VHF6Pn6CaUuoFi6WmSC1a3DuaqYOKOUB/Sr9upNMDm+diupW3efKh4MDQEjqkrR38D
 l0dOtisSevnv9VvCQR76z8z4bMWM=
X-Google-Smtp-Source: AGHT+IGTKAKkNLy6a6Akixhu2h9dy/g5ZLnrTx0xEha9XhrwZGWYAtu4uekaJu1ehmU4mKhuv+ew3gQ4TGHljwFkY4w=
X-Received: by 2002:aa7:d98d:0:b0:57d:6326:c658 with SMTP id
 4fb4d7f45d1cf-57d6326cb46mr619601a12.0.1719213006975; Mon, 24 Jun 2024
 00:10:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
 <86ed8pjwgc.fsf@HIDDEN>
 <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
 <86wmmgg7un.fsf@HIDDEN>
In-Reply-To: <86wmmgg7un.fsf@HIDDEN>
From: Mitchell <mitchellahren@HIDDEN>
Date: Mon, 24 Jun 2024 01:09:29 -0600
Message-ID: <CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000092fd60061b9d78f3"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000092fd60061b9d78f3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I am not a programmer by trade. I did previously manage to build the latest
version of emacs on Windows as explained at
https://readingworldmagazine.com/emacs/2022-02-24-compiling-emacs-29-from-s=
ource-on-windows/
, but after several hours trying to compile a version of emacs rolled back
to just before that commit, I haven=E2=80=99t had luck. I git-cloned emacs =
master
to my machine, used `git checkout 8783700b23e70874c4996908bf02c010ae6f3fe1^=
`
to narrow down to the parent of the commit in question, ran `./autogen.sh`
and then `./configure`, and finally tried `make`, but it keeps raising
errors. ChatGPT diagnoses the errors like this:

Warnings:
    calloc Argument Order: Multiple warnings about the incorrect order of
arguments in calloc calls. The first argument should specify the number of
elements, and the second argument should specify the size of each element.
For example:
           c
           newstate =3D (re_dfastate_t *) calloc(1, sizeof(re_dfastate_t));
    These warnings alone should not cause the build to fail but should be
corrected for code correctness and stability.
Errors in sysdep.c:
    Implicit Declaration of waitpid:
             sysdep.c:472:13: error: implicit declaration of function
'waitpid' [-Wimplicit-function-declaration]
            472 | pid =3D waitpid(child, status, options);
This error indicates that waitpid is being used without including the
proper header file that declares it.
Undeclared Identifier WNOHANG:
           sysdep.c:518:43: error: 'WNOHANG' undeclared (first use in this
function)
           518 | return get_child_status(child, status, WNOHANG | options,
0);
This suggests that WNOHANG is not defined, likely because the appropriate
headers are not included.
Control Reaches End of Non-Void Function:
           sysdep.c:519:1: warning: control reaches end of non-void
function [-Wreturn-type]
    519 | }
    This means the function is expected to return a value but doesn't in
all code paths.
Error in print.c:
    Storing the Address of Local Variable:
        process.c:7419:53: error: storing the address of local variable
'buf' in 'current_thread->stack_top' [-Wdangling-pointer=3D]
This indicates a potential issue with a dangling pointer, where the address
of a local variable is being assigned to a global or long-lived structure.

If you have any advice I=E2=80=99m happy to try compiling it again. Or perh=
aps Ihor
or Stefan would have more luck rolling back emacs to just before that
commit to confirm that=E2=80=99s the issue? Sorry!

--00000000000092fd60061b9d78f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I am not a programmer by trade. I did previously mana=
ge to build the latest version of emacs on Windows as explained at <a href=
=3D"https://readingworldmagazine.com/emacs/2022-02-24-compiling-emacs-29-fr=
om-source-on-windows/">https://readingworldmagazine.com/emacs/2022-02-24-co=
mpiling-emacs-29-from-source-on-windows/</a> , but after several hours tryi=
ng to compile a version of emacs rolled back to just before that commit, I =
haven=E2=80=99t had luck. I git-cloned emacs master to my machine, used `<c=
ode class=3D"gmail-!whitespace-pre gmail-hljs gmail-language-sh">git checko=
ut 8783700b23e70874c4996908bf02c010ae6f3fe1^</code>` to narrow down to the =
parent of the commit in question, ran `./autogen.sh` and then `./configure`=
, and finally tried `make`, but it keeps raising errors. ChatGPT diagnoses =
the errors like this: <br></div><div><br></div><div>Warnings:<br>=C2=A0 =C2=
=A0 calloc Argument Order: Multiple warnings about the incorrect order of a=
rguments in calloc calls. The first argument should specify the number of e=
lements, and the second argument should specify the size of each element. F=
or example:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 c<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0=C2=A0 =C2=A0 newstate =3D (re_dfastate_t *) calloc(1, sizeof(=
re_dfastate_t));<br>=C2=A0 =C2=A0 These warnings alone should not cause the=
 build to fail but should be corrected for code correctness and stability.<=
br>Errors in sysdep.c:<br>=C2=A0 =C2=A0 Implicit Declaration of waitpid:<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
ysdep.c:472:13: error: implicit declaration of function &#39;waitpid&#39; [=
-Wimplicit-function-declaration]<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 472 | pid =3D waitpid(child, status, options);<=
br>This error indicates that waitpid is being used without including the pr=
oper header file that declares it.<br>Undeclared Identifier WNOHANG:<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sysdep.c:518:43: =
error: &#39;WNOHANG&#39; undeclared (first use in this function)<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 518 | return get_chi=
ld_status(child, status, WNOHANG | options, 0);<br>This suggests that WNOHA=
NG is not defined, likely because the appropriate headers are not included.=
<br>Control Reaches End of Non-Void Function:<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0=C2=A0 =C2=A0 sysdep.c:519:1: warning: control reaches end of non-void f=
unction [-Wreturn-type]<br>=C2=A0 =C2=A0 519 | }<br>=C2=A0 =C2=A0 This mean=
s the function is expected to return a value but doesn&#39;t in all code pa=
ths.<br>Error in print.c:<br>=C2=A0 =C2=A0 Storing the Address of Local Var=
iable:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 process.c:7419:53: err=
or: storing the address of local variable &#39;buf&#39; in &#39;current_thr=
ead-&gt;stack_top&#39; [-Wdangling-pointer=3D]<br>This indicates a potentia=
l issue with a dangling pointer, where the address of a local variable is b=
eing assigned to a global or long-lived structure.</div><div><br></div><div=
>If you have any advice I=E2=80=99m happy to try compiling it again. Or per=
haps Ihor or Stefan would have more luck rolling back emacs to just before =
that commit to confirm that=E2=80=99s the issue? Sorry!<br></div></div>

--00000000000092fd60061b9d78f3--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 24 Jun 2024 12:39:02 +0000
Resent-Message-ID: <handler.71644.B71644.17192327036440 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: monnier@HIDDEN, Mitchell <mitchellahren@HIDDEN>
Cc: 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17192327036440
          (code B ref 71644); Mon, 24 Jun 2024 12:39:02 +0000
Received: (at 71644) by debbugs.gnu.org; 24 Jun 2024 12:38:23 +0000
Received: from localhost ([127.0.0.1]:55758 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sLixj-0001fm-8i
	for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 08:38:23 -0400
Received: from eggs.gnu.org ([209.51.188.92]:42470)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sLixh-0001fH-QP
 for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 08:38:22 -0400
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 <eliz@HIDDEN>)
 id 1sLixa-0004qk-2P; Mon, 24 Jun 2024 08:38:15 -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=aRfTJZLv+1aILObIajvJsdadKSrKYmbgrDy7m3ox8uk=; b=ceTlI9OFryrbS9ptq7BE
 eIGBYu7a6XayozVj1x+7wZ86gs/4mneirfLobJyWyOu4tW9782TWZ+OpcAqIaz+uySIpvlWacb2Hy
 x4M36jTD2hpQXNamKKTz//YdUbfvm1yPSF3J56xlYfDjvjO0kjNGll2YqJP7vodfASEQN1KJAz443
 272FnJ6lceNvV/m4Julbr1GYVSrgkkj7ct+8GhpyRhEPI1wPMc1QQNea9H13Gf/9ExVyAlQOMVGup
 6mDHepyjHLFiPa5DW46+m0LQvYgl7C4nwj9WWmVrK9JxHXb6qCtxZMP0GuOdzmwEUCPDsmEE6x3dc
 RYm7JYhJ3hUVSQ==;
Date: Mon, 24 Jun 2024 15:38:12 +0300
Message-Id: <86msnabjnv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN>
 (message from Mitchell on Mon, 24 Jun 2024 01:09:29 -0600)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
 <86ed8pjwgc.fsf@HIDDEN>
 <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
 <86wmmgg7un.fsf@HIDDEN>
 <CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Mitchell <mitchellahren@HIDDEN>
> Date: Mon, 24 Jun 2024 01:09:29 -0600
> Cc: monnier@HIDDEN, 71644 <at> debbugs.gnu.org
> 
> I am not a programmer by trade. I did previously manage to build the latest version of emacs on Windows as
> explained at
> https://readingworldmagazine.com/emacs/2022-02-24-compiling-emacs-29-from-source-on-windows/ , but
> after several hours trying to compile a version of emacs rolled back to just before that commit, I haven’t had
> luck. I git-cloned emacs master to my machine, used `git checkout
> 8783700b23e70874c4996908bf02c010ae6f3fe1^` to narrow down to the parent of the commit in question,
> ran `./autogen.sh` and then `./configure`, and finally tried `make`, but it keeps raising errors. ChatGPT
> diagnoses the errors like this: 

Sorry, I haven't realized you don't have a fully operational build
environment for Emacs.  The errors you show mean that your development
environment is broken.

So please forget this.

Maybe someone else could try reverting that change?  Stefan, could you
do that, since you see the regression wrt Emacs 28 on your system?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 03:08:01 +0000
Resent-Message-ID: <handler.71644.B71644.171928486727312 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171928486727312
          (code B ref 71644); Tue, 25 Jun 2024 03:08:01 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 03:07:47 +0000
Received: from localhost ([127.0.0.1]:35909 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sLwX5-00076S-0S
	for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:07:47 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20675)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sLwX0-000769-HD
 for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:07:45 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 39CAC10016C;
 Mon, 24 Jun 2024 23:07:34 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719284853;
 bh=qoSMD/e8SLLYtaKGGfGnV1WzYdl90Rh6hK2rxkC2N+k=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Btwm8XNMOVBlCE4Q6kQFrzUWCpn8biTXIw5gmt1F2Jo9VAE1oRjnNB9r54Z2jYiL2
 sip/tqk+Rr7fx8NYawPJTzVt01BCzgi9DkskBvOmBNwhPVGYpSzDhOYuJ5iXo4Qgah
 H1AmlNvs+wAdS59Z4o5DqfQEyW/zcrShEQZhgiY5z55CZXT9AIFc4EaQLCjovfMx54
 HE4AdZ5ZkyThJIe0crZEqye2wuOdgoev7hTa0Cf24fm/r28fCbINhC47Usto2rMIHo
 e33UGc9hpdBX/3K7xLvrLB06e83Wo6yg2WyUg3/2LtkbfDWC7XMEOfDjADsFkTzrp0
 oI75/z5Y6ZfjA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 150E2100048;
 Mon, 24 Jun 2024 23:07:33 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D47E7120170;
 Mon, 24 Jun 2024 23:07:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87wmmhgjao.fsf@localhost> (Ihor Radchenko's message of "Sat, 22
 Jun 2024 14:10:23 +0000")
Message-ID: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost>
Date: Mon, 24 Jun 2024 23:07:32 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.142 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the
version included in Emacs-28.2) the recipe doesn't show the slowdown.

There's still a good chance that the slow behavior is due to
chars<->bytes conversion (there's no doubt that this code's performance
can be quite poor), but I suspect the reason for the change of behavior
between Emacs-28 and Emacs-29 lies in Org rather than in Emacs's C code.
If someone more familiar with the changes that occurred in Org around
that time could try and track down the specific change that triggers the
problem, that would be appreciated.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 03:09:02 +0000
Resent-Message-ID: <handler.71644.B71644.171928493627427 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171928493627427
          (code B ref 71644); Tue, 25 Jun 2024 03:09:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 03:08:56 +0000
Received: from localhost ([127.0.0.1]:35914 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sLwYC-00078I-FA
	for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:08:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21148)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sLwYA-000783-4C
 for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:08:54 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 512AB8053A;
 Mon, 24 Jun 2024 23:08:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719284926;
 bh=C47KbCiCMgzkJRZ1fGG20MMMJsU5J3bKw8sUbhiEtAw=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=ktkfYh6gdZdEJBAilEQw3VoCDr0ewyqXQExzoCZ0hjIKERTt2lXxQWKZtDPa+2krt
 vUBeiTdsOCVAaESxxMBYiXzM5Sz+HVTZ7bSj4T9OMiZ47uNsHq7yZEzjYaOdlYsk4t
 Ph9Dxq8FZKPzq4QBjJY8Ec6ZKU12OJbFnx08X3BXdiNgMP33DdCkUIArPioPwJPN5m
 NkGcZgjITFNgKvkT0d4+cNh2r7aMQ/1nloDOL05KQrm1BCd+rJWyQeQZ9Yqgz7LNuq
 5LYKty935OtvbF1km96cYQ31b+SauecKOvh1wCzyEQJSaTDxmxppf4NdMzGLpEfn+G
 Y95NlicDCbiMQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 26B65805DE;
 Mon, 24 Jun 2024 23:08:46 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC5B912033B;
 Mon, 24 Jun 2024 23:08:45 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <86msnabjnv.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 24 Jun
 2024 15:38:12 +0300")
Message-ID: <jwv5xtx2004.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
 <86ed8pjwgc.fsf@HIDDEN>
 <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
 <86wmmgg7un.fsf@HIDDEN>
 <CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN>
 <86msnabjnv.fsf@HIDDEN>
Date: Mon, 24 Jun 2024 23:08:44 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.048 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Maybe someone else could try reverting that change?  Stefan, could you
> do that, since you see the regression wrt Emacs 28 on your system?

Removing that patch made no difference in my tests on Emacs-29.
[ And adding it to Emacs-28 also made no difference, in my tests.  ]


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 04:01:02 +0000
Resent-Message-ID: <handler.71644.B71644.1719288059895 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.1719288059895
          (code B ref 71644); Tue, 25 Jun 2024 04:01:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 04:00:59 +0000
Received: from localhost ([127.0.0.1]:35967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sLxMY-0000EI-PL
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 00:00:59 -0400
Received: from eggs.gnu.org ([209.51.188.92]:50906)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sLxMX-0000E7-MD
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 00:00:58 -0400
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 <eliz@HIDDEN>)
 id 1sLxMP-0005UK-3a; Tue, 25 Jun 2024 00:00:49 -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:In-Reply-To:Subject:To:From:
 Date; bh=9Tk/8+B9VzNhqDU+/mOHKn0SNSevPCAeuzVa+LOihqU=; b=XTkXobmxNwtQQVYeDaw1
 fYRH1nsc72yiQG7CjT7Vikxesics81PKBDWzF4us/lSWOQ7+0oZRboEkDK4558GJ25cbqxthipKfl
 WQKICOA4ekOX+4isNy1sNZHkQihqC2g0faA8KeWYvBwM/SPh1aacibyeGT3bE8+FKzMISb5kTkUGC
 AA7nZjJzuSfdTyRmnYlc6pPeK/MRNH/J3rOsnxe7Em4luOoXpwLTq92dfTADchk0I8zmtH5EPmzXF
 ipA10nrZIb54MFuJ0LG3RSTmjppzSL+jxmCVplFlixSqjq6OULhOzNChWoAz8us/G75hvzL/D6m98
 vmdvvUK8AK1CSg==;
Date: Tue, 25 Jun 2024 07:00:38 +0300
From: Eli Zaretskii <eliz@HIDDEN>
User-Agent: K-9 Mail for Android
In-Reply-To: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
Message-ID: <71F78866-48D2-4973-91A7-8E9652E49CE7@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Autocrypt: addr=eliz@HIDDEN; keydata=
 mQENBF+pf4UBCAC6vjkWLSAsQpe8YIGKLQzNOJx/IjGtCdFF8uzmO5jmME+SD8ROuJN+t5KXVw58
 uzu75EFD0vHTY9e+udJ2gkpuy0NnzkFcbumdLLo2ERKCoSctZZRhzKXI5z5cHxCqW0B2ygHRrRLt
 oNlGID7bAgcgSViT1ptGqTXO7zGVu4Airok7dNzcPtHgns8GlR5YAFX0TvE6oGd0l2VPghNeVJKJ
 OjrbfhoDxl3ucFpqbqMH8z9HTLDOFpz8UaYYUdJMi3xX6vwTZxI2sM2RRVLUpZyllAkSMI4lln1O
 OgazM/62DJUs/rKIHKBnF6h3/qsJUjUYXaAHbrXY26mWllAd536lABEBAAG0I0VsaSBaYXJldHNr
 aWkgKGVsaXopIDxlbGl6QGdudS5vcmc+iQE4BBMBAgAiBQJfqX+FAhsDBgsJCAcDAgYVCAIJCgsE
 FgIDAQIeAQIXgAAKCRCRwSYvAeuNOYUQB/4/iIKKOG45ijNaRoTvmJJZMvj1S07WQxEm7c5SHEeE
 QbLOAxB9vESOV7sLueuN3oqEndtzyYt4x1WTSBmHFF7h5fcCMjBs41siOIp5Sj/xD0Bvaa0IKGCR
 SZ7PAo8Mq3wgajXpTpn9vxE2PmtzA8KdEE0K1+f9pVAfOpUIcCl44rIxLUW352XG0y7iz6c/O6LB
 1deOKMiKFctKO7pBti1dJEm1ImewLH3H8uTbwspLOs3EB8xhsESxmTidnze68HX2jt+2EeMgCdki
 NU+LWbexQZPfIS7+ZmE06ll0v6+Jy7ZdTkCCRypKWTnW7pIFsq/p4kybV8O/kHSV6B4vvQBfuQEN
 BF+pf4UBCACvFrdx/m22lgObypSmSS4TNlNvQnMUorrMmp0U32hv5adt6CKXeMjk05F+GcIfVMrp
 xqMBn4sEUIXWhhogQJa9ZbWEP/HbS8XjMMbz0Q0Siaty9+DSspK/9u2GWKsz3uQzLCexIJtzmXvj
 AVmvoMCAU/F2t038ggygjYLRgyLRNLgbbartu2dMkvrfxRjheip60S4S3utOcwUf/qdoa1grNann
 CFluHr/ftXCeeuGB4H8iO0BXWNby6NZPizxJttx9gdcH8/OmDOJkXyRMTT/3sSem76CSOjfXcz7s
 aJlg680NQhG5TmuYERjJD4+U02K5RuqTsEnOuWeFy4p+/mslABEBAAGJATYEGAECAAkFAl+pf4UC
 GwwAIQkQkcEmLwHrjTkWIQTmyQKcNjrUHXh6jruRwSYvAeuNOejsB/9rVegsfEBSRLjeeYXyJrOf
 dme7BYpYsQCw2vGTnrJTGFQ9HM2zT9+wAENBHWjQPJOptJwo5w4xIbZgwJy0uIN3sV18xbCRSxX0
 ZSk8GJG0PrQTCaf2xs0kqsShnkvqyo5QSyUlFUAG7m1o7NUhF95Q89oxGO8JyvR356kqNbzUn0Cq
 PxKyS42QfC8dyFNgVhVPbZp6aONnUwY5SbtCLJtZCBgvppI9XaBH41BDukSE4GgSLoYsSIGShg4h
 e+bGypAsGtQ9uwmryUi1gRrDgca3wFo/G0rbJn2ZKoLbGFZivWPVgAgd9/O5sLSPFznOdcRGxEA2
 gk7A1ReaJ10PtQz0
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

On June 25, 2024 6:07:32 AM GMT+03:00, Stefan Monnier <monnier@iro=2Eumontr=
eal=2Eca> wrote:
> One other thing I notice: If I use Emacs-29 but with Org-9=2E5=2E5 (i=2E=
e=2E, the
> version included in Emacs-28=2E2) the recipe doesn't show the slowdown=
=2E
>=20
> There's still a good chance that the slow behavior is due to
> chars<->bytes conversion (there's no doubt that this code's performance
> can be quite poor), but I suspect the reason for the change of behavior
> between Emacs-28 and Emacs-29 lies in Org rather than in Emacs's C code=
=2E
> If someone more familiar with the changes that occurred in Org around
> that time could try and track down the specific change that triggers the
> problem, that would be appreciated=2E
>=20
>=20
>         Stefan
>=20
>=20

Yes, I think it is very important to find out which changes in Org trigger=
ed this issue in Emacs 29=2E

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 09:29:02 +0000
Resent-Message-ID: <handler.71644.B71644.171930771611770 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171930771611770
          (code B ref 71644); Tue, 25 Jun 2024 09:29:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 09:28:36 +0000
Received: from localhost ([127.0.0.1]:36285 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sM2Tc-00033l-9K
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 05:28:36 -0400
Received: from mout02.posteo.de ([185.67.36.66]:49111)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sM2TW-00033O-N6
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 05:28:34 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id D5126240105
 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 11:28:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1719307702; bh=FNN410BJCRIKpK57AcZmk4AGbAs65bj6TxFcoz8I14w=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=E42OiyISD4+4tvu5i4rsg6n4BKQxCMspPYkrXJYC5bo9WBb2ZjsamqgeqEZcYRD3z
 gJSKqS5DIG9uImG7D7uF+Yuli/nOeg7p4LgTy8w7umj8Zt1ffls/YE1tNBpMu5Jj07
 yPp3ZNWdwazpPZ9AYqB+olsTFIO7Ds4J7iFMv8BT3VLey1mdX8j2COkNxptvX3QZKS
 p1uOallGUOczVcLIb/GE08LzncG4942FOrJAeMf8nFmk48/aR3BzTf6XBoooYK8PBt
 NfliHXlByVMOTb5LeY+mlH87ZHxtaPH9ga8bqOo83bWHNYsRLbOIA6dBJ8ES1V6VBa
 hzVNuQC/LRoFQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W7fdd027Qz9rxD;
 Tue, 25 Jun 2024 11:28:20 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
Date: Tue, 25 Jun 2024 09:30:00 +0000
Message-ID: <87le2t5q07.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

> One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the
> version included in Emacs-28.2) the recipe doesn't show the slowdown.
> ...
> If someone more familiar with the changes that occurred in Org around
> that time could try and track down the specific change that triggers the
> problem, that would be appreciated.

The biggest suspect is the fact that Org switched from overlay-based
folding to text property-based between Org 9.5 and Org 9.6.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 13:46:02 +0000
Resent-Message-ID: <handler.71644.B71644.171932310316998 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171932310316998
          (code B ref 71644); Tue, 25 Jun 2024 13:46:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 13:45:03 +0000
Received: from localhost ([127.0.0.1]:36530 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sM6Tm-0004Q5-SU
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:45:03 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35278)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sM6Tk-0004PH-CJ
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:45:01 -0400
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 <eliz@HIDDEN>)
 id 1sM6Td-0005sI-33; Tue, 25 Jun 2024 09:44:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=hHq+6EHPSj2CvsDG3HWp02ykpAK44tCGasBcBP66Ekw=; b=JPxFqUjyclmA
 6J7vq9FGSsC6TbZdg01QkPPriplrj7lj40mXb/Hcjrv5FkS+v6GXbKbJJCCQZzjsCCI9BosvF9pCF
 hitguLv7eO3QLQwPduTYTVVrbWMRg9aBDWuEV9vb3yeEwMxQvlodEnArBxCN0CInN3AsIuQtefuiO
 dxKK2fbY46VilUVt6tCs5g3/LNJ/rEk7obm9o/vW/NLWLE3nneP0fkrLhmTmSYMfbFel+GCKE82Dv
 TP5sman/2Dd76wi+hMQ7IxEvSiF7QJmIUdLnnmNrmh6uCmHBDUzxd/5LD1wAykPqcu84dZm+029AR
 lSwZtaTQ6xZCQwvm61JMsw==;
Date: Tue, 25 Jun 2024 16:44:48 +0300
Message-Id: <86o77p9lwv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87le2t5q07.fsf@localhost> (message from Ihor Radchenko on Tue,
 25 Jun 2024 09:30:00 +0000)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <87le2t5q07.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
>  71644 <at> debbugs.gnu.org
> Date: Tue, 25 Jun 2024 09:30:00 +0000
> 
> Stefan Monnier <monnier@HIDDEN> writes:
> 
> > One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the
> > version included in Emacs-28.2) the recipe doesn't show the slowdown.
> > ...
> > If someone more familiar with the changes that occurred in Org around
> > that time could try and track down the specific change that triggers the
> > problem, that would be appreciated.
> 
> The biggest suspect is the fact that Org switched from overlay-based
> folding to text property-based between Org 9.5 and Org 9.6.

But overlays aren't supposed to be faster than text properties, so I'm
unsure why this change would have such an effect.

However, it is important to establish the facts first, and try to
explain them later.  So if you could come up with a change to try on
top of Org 9.6 that would change it back to use overlays for folding,
we could try that and see if the slowdown goes away, and take it from
there.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 13:49:02 +0000
Resent-Message-ID: <handler.71644.B71644.171932333817397 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171932333817397
          (code B ref 71644); Tue, 25 Jun 2024 13:49:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 13:48:58 +0000
Received: from localhost ([127.0.0.1]:36535 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sM6XZ-0004WX-KY
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:48:57 -0400
Received: from mout02.posteo.de ([185.67.36.66]:57177)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sM6XX-0004WG-AB
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:48:57 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id E284C240101
 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 15:48:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1719323326; bh=L3j5zGMypHOE/0UsXGuk39lOMDDPqhGAwmo1xAtDp5s=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=LKTAqqnjcWTOp8zYMvdGvpBnjaceJh/1zWrcYULWElqSP6sZ2M+xxJclFg7nflKuk
 ALG2ZeKYwz+wjfG6sq4iCTnyu5ONHePmk1zhdmuDNyBB1MbWVYnGlTIiTn+hqVD98Y
 NNtAetFoBnioepEWYRb7P/FiMoj0Y/X3lupoFvnNEZQ0w2UUtWbfa3yL0N+AgLHB/p
 A+3dBmb5yIOAdfTiLbXK0QGce6ZTFU2VFTsGiLb4ORVU585RW5Te4AmPGBkY47hxDn
 BGDnCYoEBuwVcKQiBUMJWSI7PQteO2nZlgwoq5Izg6wBh8uS3U8cK0EkEfVPDv9VTY
 63/yKRlDQsHhQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W7mQ569YDz6twM;
 Tue, 25 Jun 2024 15:48:45 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <86o77p9lwv.fsf@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN>
Date: Tue, 25 Jun 2024 13:50:21 +0000
Message-ID: <87frt15dya.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

> ...  So if you could come up with a change to try on
> top of Org 9.6 that would change it back to use overlays for folding,
> we could try that and see if the slowdown goes away, and take it from
> there.

(setq org-fold-core-style 'overlays) ; before Org is loaded

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 13:58:02 +0000
Resent-Message-ID: <handler.71644.B71644.171932386919132 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171932386919132
          (code B ref 71644); Tue, 25 Jun 2024 13:58:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 13:57:49 +0000
Received: from localhost ([127.0.0.1]:37493 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sM6g8-0004yV-Lp
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:57:48 -0400
Received: from eggs.gnu.org ([209.51.188.92]:48018)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sM6g6-0004yH-Fd
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:57:47 -0400
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 <eliz@HIDDEN>)
 id 1sM6fz-0000Ip-1x; Tue, 25 Jun 2024 09:57:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=KxruSHo4ACUi0W+1atzIYADcEfA7CmuHETld4hnL3AE=; b=Bq+yzu7DXYld
 DKIyg0n+06O/DbefRDFbjoiuMLwheNMcziGHkn6qYZJKd/MdQZacqb8sj4XUJ7jzpRp09lqSHo0LA
 BJJvlgwWztu9V1nXye6gVP9U/1g2nWuQjK1KIpanuf7M52U8hFz9zhdnYdptDR4+zUQEOqFC0gV9l
 5nrzDKxqH++EELJOY1gNReAOyNah6zQGHp8TRA8Lv5HSianE8Ft/sDFmDw4Fi3Y4BdZoetmrPPwP6
 1K+dHEt/xB6qqZaIUBs0SeBu7PZ04iS+1Q5I8ifN809HFkeJYyuli/k6LAvbaIITs4h4A0Wu0pg1+
 lABfXFcdv/13Z5g1udEWVw==;
Date: Tue, 25 Jun 2024 16:57:36 +0300
Message-Id: <86jzid9lbj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87frt15dya.fsf@localhost> (message from Ihor Radchenko on Tue,
 25 Jun 2024 13:50:21 +0000)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> <87frt15dya.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
> Date: Tue, 25 Jun 2024 13:50:21 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> > ...  So if you could come up with a change to try on
> > top of Org 9.6 that would change it back to use overlays for folding,
> > we could try that and see if the slowdown goes away, and take it from
> > there.
> 
> (setq org-fold-core-style 'overlays) ; before Org is loaded

Thanks.  Mitchell and Stefan, can you try this?

P.S. For some reason, Stefan's email server rejects my mails "due to
abuse", I hope it could be fixed soon.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 14:24:02 +0000
Resent-Message-ID: <handler.71644.B71644.171932542621743 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171932542621743
          (code B ref 71644); Tue, 25 Jun 2024 14:24:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 14:23:46 +0000
Received: from localhost ([127.0.0.1]:37521 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sM75G-0005ed-7I
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 10:23:46 -0400
Received: from mout02.posteo.de ([185.67.36.66]:39793)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sM75B-0005eL-US
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 10:23:45 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 7C7A6240101
 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 16:23:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1719325412; bh=1nlarY+0s4sSc/fPNWCJd4vffrXl6UkQ1fbiOg2ltVs=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=Mh3M6aH9X5X5YNvZ9iin7xKyk81bq6P/lC+YG1VDX7KRjULigYqDcVZfqG7+L2THl
 +ATjHN3EiekQQuHFNSE0LeIP21dvdK2NuoHPq2kIvUa8t7rwGInIoQaKdnoayqG8pi
 KTHoSx5rPfO5kqRxD/sF+aFLmD8BV5G9qOABdjzkvJC6IdOhGvAxaFZQvZJnAQ+MDa
 KkYziM2ShQ2fASLrOspE4yfLm8bX8ikHbdO/gKjTE5TZdrEvNdkHW4IOmMuBgcGFeB
 tmVRsQPMUyfdU+MSd0BbN8T9lb+kMLTK2YN0Odu55F0NdHRMSte+amqJaM1BmWLNA7
 z7Tl0ASfq/7fA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W7nBC2NCpz9rxK;
 Tue, 25 Jun 2024 16:23:31 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <86jzid9lbj.fsf@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN>
 <87frt15dya.fsf@localhost> <86jzid9lbj.fsf@HIDDEN>
Date: Tue, 25 Jun 2024 14:25:06 +0000
Message-ID: <87cyo55ccd.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

> P.S. For some reason, Stefan's email server rejects my mails "due to
> abuse", I hope it could be fixed soon.

Same for me.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 21:16:02 +0000
Resent-Message-ID: <handler.71644.B71644.171935012826320 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171935012826320
          (code B ref 71644); Tue, 25 Jun 2024 21:16:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 21:15:28 +0000
Received: from localhost ([127.0.0.1]:37712 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMDVY-0006qF-ID
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:15:27 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32985)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sMDRG-0006jZ-3I
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:15:16 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 70A6D8092E;
 Tue, 25 Jun 2024 17:02:11 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719349326;
 bh=0y0Zy5kTjvwVSW6UtOfjWYqDuw9PaJieDDsPSSUNBhM=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=OVnFJxTJ8sGqatU/uG8IC++YXG9AeGGvmlaqlClvVkXzNmGkbkEojUmpbUqCNsXfX
 LyJ0Va0TxMzpzaRX9Su9RxsSW63uf9WUsn6A2fwghyNK5Wr0D/alBTWEH/PjV5TmBd
 P+dfXg8EsVc9Mg6Y3R+RRBQyaKfGCykWNlOhLrB+DRLBsBG+PVmnvrT0BTS+EVCW1E
 FBxYV/R3Lc2tpQ+q9ghzawTXXWeJk2PCObN7T+x3iAVeyrAcGrzU5DpcmnS65RUOk3
 km61mrmDF7RnTtU4WRE2sREQXiXGcpoUxUkmZOvHSecMSIZw20yEZQj+tDFrpAuix2
 ClKW67fY+GsMA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 067CA8014E;
 Tue, 25 Jun 2024 17:02:06 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E7BDB1205EF;
 Tue, 25 Jun 2024 17:02:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87wmmhgjao.fsf@localhost> (Ihor Radchenko's message of "Sat, 22
 Jun 2024 14:10:23 +0000")
Message-ID: <jwvzfr8ybyj.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost>
Date: Tue, 25 Jun 2024 17:02:05 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.099 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Yup. I _do not_ propose my patch to be merged.
> (BTW, we should probably merge this bug and bug#63040 where I first
> shared this patch - just to demonstrate the problem and discuss possible
> solutions)

FWIW, I'm not sure it's exactly the same problem yet.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Jun 2024 21:26:02 +0000
Resent-Message-ID: <handler.71644.B71644.171935071927172 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171935071927172
          (code B ref 71644); Tue, 25 Jun 2024 21:26:02 +0000
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 21:25:19 +0000
Received: from localhost ([127.0.0.1]:37719 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMDf4-000742-PE
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:25:19 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21675)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sMDcS-000702-7V
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:25:09 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 49FC3804BC;
 Tue, 25 Jun 2024 16:54:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719348884;
 bh=2mwNLdLwe79GliepBjpnMAu4xT60BAd0JgNplx8k3No=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=EOwVnAMJqfxCf8gX4SDqgHNDDVhRmPItqmFygSK57CZ5CxmQ2uffifW0yFl8BiBBG
 M1nVPG5/3aTlNvyMqm3XuK7q1cADKsEt1mXHmbP1HsB/u2UYahUivzk0YpF4tIWYDp
 nq7ANmkce8yrUDeJXcxfIcX43kqiOcdHM/bDRH3o/1GE1+dH7wF96zjFVzkv1l0fgL
 SVSQyzK5LDIz2tgI4lNm8qMd1AP+0ho1I3YzFgxM85Drse/fAczOVGMCGpFPpd55OB
 xkBKoKJLSS5Qq1RCbEYJNt4iu3mBs7mfoIRWQkNNAjq6DLBX5SkXMspA53ryoP/h5l
 Y3y4bqp/M6W4w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9C0D78027D;
 Tue, 25 Jun 2024 16:54:44 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8658B120635;
 Tue, 25 Jun 2024 16:54:44 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Mon, 24 Jun 2024 23:07:32 -0400")
Message-ID: <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
Date: Tue, 25 Jun 2024 16:54:44 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.931 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain LONGWORDS               2.035 Long string of long words
X-SPAM-LEVEL: 
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: > One other thing I notice: If I use Emacs-29 but with
 Org-9.5.5
 (i.e., the > version included in Emacs-28.2) the recipe doesn't show the
 slowdown. One more thing: when I use Mitchell's recipe, sometimes buffer edits
 are immediate and sometimes they're not (I mean, when following the recipe
 exactly, it's not immediate, but if I do things slightly [...] 
 Content analysis details:   (1.8 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 T_SPF_TEMPERROR        SPF: test of record failed (temperror)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.8 LONGWORDS              Long string of long words
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.8 (/)

> One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the
> version included in Emacs-28.2) the recipe doesn't show the slowdown.

One more thing: when I use Mitchell's recipe, sometimes buffer edits are
immediate and sometimes they're not (I mean, when following the recipe
exactly, it's not immediate, but if I do things slightly differently and
sometimes after doing other(?) things, it's immediate again).

When I'm in the "state" where editing is not
immediate, it seems to apply only to edits done right before or right
after a header: edits elsewhere (e.g. within some paragraph) are
still "instant".

Oh, and typing text at the end of a header seems to get me out of that
state, somehow (and I don't know how to get back into that state, tho
it sometimes happen).

BTW, my test case is now a large (26MB, 640kLines) Org file consisting of a=
 long
repetition of:

    * asdgasgasdfgsd=E9adfgasdgafg
=20=20=20=20
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh
=20=20=20=20
    ** sf na;l bnsdkh bsadlfv asdl fkbasldfv alsfkg v
=20=20=20=20
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
    asdfadfkh asdfadfkh

I instrumented the bytes<->chars routines to try and keep track of what
happens there.  This gives me a histogram showing how many times the
conversion routines consulted N markers as well as another histogram
telling me how many times those routines scanned between M*100B and
(M+1)*100B of text.
Oh and it gives me the number of markers in the buffer as well (the
histogram is not buffer-local, but there's basically only one buffer in
that session).

The result are below (followed by the actual code).
There are several odd things in there:

- The markers histogram is weirdly flat.
- The markers histogram seems to have a threshold around 800
  I can't explain.  It seems directly related to the buffer size, tho:
  with a file half the size, I get half as many markers (40k) and
  a threshold in the histogram around 400.
- The number of times we consider exactly 1 marker is probably "too
  high" because the C code happens to look at the first marker before
  checking if it's necessary.

(80044 :markers
 ((0 16) (1 3290720) (2 28912) (3 34427) (4 30479) (5 71089) (6 29858)
  (7 29855) (8 29953) (9 30156) (10 30251) (11 30185) (12 30999)
  (13 30270) (14 30530) (15 30332) (16 30175) (17 30278) (18 30187)
  (19 30316) (20 29698) (21 29760) (22 29674) (23 29695) (24 29682)
  (25 29689) (26 29699) (27 29835) (28 30483) (29 30455) (30 30444)
  (31 30313) (32 29666) (33 29696) (34 29739) (35 29781) (36 29694)
  (37 29726) (38 29722) (39 29729) (40 29721) (41 29800) (42 29846)
  (43 29751) (44 29775) (45 29780) (46 29782) (47 29788) (48 29869)
  (49 29891) (50 29811) (51 29823) (52 29834) (53 29817) (54 29833)
  (55 29901) (56 29927) (57 29854) (58 29836) (59 29856) (60 29843)
  (61 29835) (62 29918) (63 29928) (64 29851) (65 29858) (66 29857)
  (67 29859) (68 29854) (69 29934) (70 29907) (71 29859) (72 29848)
  (73 29859) (74 29859) (75 29875) (76 29916) (77 29904) (78 29865)
  (79 29840) (80 29867) (81 29857) (82 29853) (83 29948) (84 29887)
  (85 29861) (86 29852) (87 29850) (88 29866) (89 29880) (90 29935)
  (91 29881) (92 29862) (93 29843) (94 29858) (95 29857) (96 29892)
  (97 29931) (98 29878) (99 29856) (100 29848) (101 29855) (102 29856)
  (103 29904) (104 29931) (105 29866) (106 29867) (107 29849)
  (108 29843) (109 29876) (110 29906) (111 29917) (112 29859)
  (113 29862) (114 29851) (115 29852) (116 29867) (117 29910)
  (118 29922) (119 29848) (120 29862) (121 29858) (122 29837)
  (123 29873) (124 29922) (125 29910) (126 29852) (127 29864)
  (128 29852) (129 29852) (130 29866) (131 29916) (132 29928)
  (133 29833) (134 29863) (135 29864) (136 29844) (137 29864)
  (138 29923) (139 29923) (140 29842) (141 29854) (142 29864)
  (143 29844) (144 29882) (145 29907) (146 29921) (147 29856)
  (148 29838) (149 29864) (150 29873) (151 29854) (152 29925)
  (153 29906) (154 29844) (155 29854) (156 29858) (157 29866)
  (158 29885) (159 29917) (160 29888) (161 29860) (162 29831)
  (163 29865) (164 29874) (165 29888) (166 29907) (167 29887)
  (168 29862) (169 29844) (170 29850) (171 29880) (172 29887)
  (173 29929) (174 29861) (175 29864) (176 29849) (177 29843)
  (178 29880) (179 29909) (180 29916) (181 29853) (182 29864)
  (183 29852) (184 29840) (185 29898) (186 29894) (187 29919)
  (188 29845) (189 29864) (190 29858) (191 29850) (192 29880)
  (193 29908) (194 29914) (195 29842) (196 29860) (197 29860)
  (198 29854) (199 29891) (200 29903) (201 29931) (202 29847)
  (203 29865) (204 29874) (205 29860) (206 29892) (207 29913)
  (208 29921) (209 29860) (210 29850) (211 29872) (212 29877)
  (213 29888) (214 29924) (215 29945) (216 29875) (217 29884)
  (218 29892) (219 29903) (220 29892) (221 29960) (222 29931)
  (223 29884) (224 29877) (225 29898) (226 29919) (227 29927)
  (228 29973) (229 29964) (230 29925) (231 29902) (232 29923)
  (233 29936) (234 29929) (235 29999) (236 29948) (237 29920)
  (238 29913) (239 29917) (240 29938) (241 29948) (242 29994)
  (243 29930) (244 29928) (245 29893) (246 29461) (247 29304)
  (248 29906) (249 29983) (250 29929) (251 29922) (252 29909)
  (253 29917) (254 29930) (255 29947) (256 30002) (257 29913)
  (258 29928) (259 29919) (260 29908) (261 29927) (262 29978)
  (263 29977) (264 29914) (265 29921) (266 29921) (267 29914)
  (268 29924) (269 29963) (270 29998) (271 29903) (272 29921)
  (273 29928) (274 29903) (275 29931) (276 29978) (277 29978)
  (278 29908) (279 29921) (280 29923) (281 29926) (282 29920)
  (283 29969) (284 29987) (285 29899) (286 29919) (287 29930)
  (288 29922) (289 29918) (290 29978) (291 29976) (292 29911)
  (293 29911) (294 29930) (295 29920) (296 29918) (297 29979)
  (298 29977) (299 29918) (300 29904) (301 29928) (302 29929)
  (303 29920) (304 29986) (305 29961) (306 29916) (307 29911)
  (308 29921) (309 29932) (310 29931) (311 29991) (312 29942)
  (313 29924) (314 29902) (315 29922) (316 29940) (317 29934)
  (318 29982) (319 29940) (320 29926) (321 29913) (322 29921)
  (323 29928) (324 29936) (325 30000) (326 29920) (327 29928)
  (328 29915) (329 29915) (330 29930) (331 29959) (332 29983)
  (333 29918) (334 29924) (335 29920) (336 29913) (337 29927)
  (338 29960) (339 29991) (340 29911) (341 29922) (342 29928)
  (343 29907) (344 29931) (345 29966) (346 29984) (347 29909)
  (348 29921) (349 29924) (350 29919) (351 29925) (352 29965)
  (353 29989) (354 29901) (355 29921) (356 29930) (357 29917)
  (358 29917) (359 29979) (360 29981) (361 29913) (362 29909)
  (363 29934) (364 29914) (365 29920) (366 29972) (367 29984)
  (368 29908) (369 29914) (370 29930) (371 29931) (372 29914)
  (373 29990) (374 29959) (375 29914) (376 29913) (377 29927)
  (378 29926) (379 29932) (380 29968) (381 29964) (382 29921)
  (383 29908) (384 29925) (385 29938) (386 29911) (387 29995)
  (388 29946) (389 29920) (390 29913) (391 29925) (392 29928)
  (393 29940) (394 29990) (395 29928) (396 29928) (397 29907)
  (398 29919) (399 29938) (400 29948) (401 29979) (402 29929)
  (403 29922) (404 29917) (405 29917) (406 29932) (407 29941)
  (408 29998) (409 29915) (410 29930) (411 29923) (412 29912)
  (413 29927) (414 29966) (415 29979) (416 29912) (417 29927)
  (418 29925) (419 29916) (420 29920) (421 29955) (422 30000)
  (423 29901) (424 29927) (425 29932) (426 29907) (427 29921)
  (428 29974) (429 29978) (430 29910) (431 29923) (432 29929)
  (433 29922) (434 29918) (435 29965) (436 29987) (437 29899)
  (438 29923) (439 29932) (440 29926) (441 29912) (442 29974)
  (443 29978) (444 29909) (445 29919) (446 29930) (447 29922)
  (448 29914) (449 29973) (450 29979) (451 29920) (452 29908)
  (453 29932) (454 29929) (455 29908) (456 29988) (457 29959)
  (458 29922) (459 29915) (460 29923) (461 29928) (462 29923)
  (463 29993) (464 29940) (465 29928) (466 29908) (467 29926)
  (468 29930) (469 29930) (470 29982) (471 29940) (472 29930)
  (473 29919) (474 29917) (475 29926) (476 29934) (477 29998)
  (478 29920) (479 29932) (480 29917) (481 29921) (482 29924)
  (483 29953) (484 29985) (485 29916) (486 29932) (487 29920)
  (488 29915) (489 29923) (490 29908) (491 29377) (492 28865)
  (493 29336) (494 29924) (495 29905) (496 29917) (497 29966)
  (498 29982) (499 29907) (500 29927) (501 29922) (502 29913)
  (503 29915) (504 29965) (505 29987) (506 29903) (507 29923)
  (508 29928) (509 29909) (510 29911) (511 29975) (512 29981)
  (513 29915) (514 29911) (515 29926) (516 29914) (517 29912)
  (518 29968) (519 29984) (520 29910) (521 29912) (522 29932)
  (523 29921) (524 29908) (525 29990) (526 29955) (527 29922)
  (528 29909) (529 29923) (530 29920) (531 29926) (532 29966)
  (533 29962) (534 29927) (535 29906) (536 29923) (537 29924)
  (538 29911) (539 29993) (540 29944) (541 29926) (542 29911)
  (543 29921) (544 29920) (545 29936) (546 29988) (547 29930)
  (548 29930) (549 29905) (550 29917) (551 29926) (552 29944)
  (553 29979) (554 29931) (555 29924) (556 29911) (557 29915)
  (558 29924) (559 29937) (560 29998) (561 29917) (562 29928)
  (563 29925) (564 29902) (565 29921) (566 29964) (567 29977)
  (568 29918) (569 29925) (570 29921) (571 29910) (572 29914)
  (573 29953) (574 29998) (575 29907) (576 29925) (577 29930)
  (578 29897) (579 29917) (580 29972) (581 29976) (582 29916)
  (583 29921) (584 29927) (585 29912) (586 29914) (587 29963)
  (588 29989) (589 29903) (590 29919) (591 29930) (592 29914)
  (593 29908) (594 29974) (595 29980) (596 29911) (597 29913)
  (598 29928) (599 29912) (600 29912) (601 29973) (602 29981)
  (603 29918) (604 29910) (605 29922) (606 29923) (607 29906)
  (608 29986) (609 29963) (610 29922) (611 29911) (612 29917)
  (613 29922) (614 29921) (615 29991) (616 29944) (617 29930)
  (618 29904) (619 29916) (620 29926) (621 29928) (622 29980)
  (623 29948) (624 29926) (625 29917) (626 29907) (627 29922)
  (628 29932) (629 30000) (630 29924) (631 29928) (632 29915)
  (633 29907) (634 29922) (635 29953) (636 29987) (637 29918)
  (638 29926) (639 29918) (640 29905) (641 29921) (642 29954)
  (643 29995) (644 29911) (645 29928) (646 29922) (647 29901)
  (648 29917) (649 29966) (650 29986) (651 29915) (652 29921)
  (653 29920) (654 29909) (655 29915) (656 29965) (657 29991)
  (658 29907) (659 29923) (660 29924) (661 29905) (662 29911)
  (663 29975) (664 29989) (665 29913) (666 29911) (667 29924)
  (668 29910) (669 29912) (670 29972) (671 29988) (672 29908)
  (673 29914) (674 29924) (675 29921) (676 29908) (677 29994)
  (678 29959) (679 29916) (680 29911) (681 29919) (682 29920)
  (683 29926) (684 29972) (685 29964) (686 29927) (687 29902)
  (688 29919) (689 29924) (690 29911) (691 29997) (692 29952)
  (693 29920) (694 29909) (695 29917) (696 29920) (697 29936)
  (698 29992) (699 29932) (700 29930) (701 29903) (702 29913)
  (703 29926) (704 29944) (705 29987) (706 29929) (707 29924)
  (708 29909) (709 29911) (710 29924) (711 29941) (712 30002)
  (713 29915) (714 29930) (715 29917) (716 29902) (717 29921)
  (718 29970) (719 29979) (720 29914) (721 29925) (722 29917)
  (723 29910) (724 29914) (725 29959) (726 30000) (727 29907)
  (728 29921) (729 29926) (730 29897) (731 29917) (732 29976)
  (733 29982) (734 29908) (735 29845) (736 29275) (737 28476)
  (738 28898) (739 29693) (740 29989) (741 29897) (742 29915)
  (743 29924) (744 29912) (745 29908) (746 29980) (747 29974)
  (748 29907) (749 29909) (750 29922) (751 29912) (752 29914)
  (753 29975) (754 29975) (755 29914) (756 29902) (757 29920)
  (758 29921) (759 29910) (760 29988) (761 29957) (762 29914)
  (763 29907) (764 29915) (765 29920) (766 29925) (767 29993)
  (768 29938) (769 29922) (770 29898) (771 29916) (772 29924)
  (773 29930) (774 29984) (775 29938) (776 29922) (777 29911)
  (778 29907) (779 29920) (780 29934) (781 30000) (782 29918)
  (783 29924) (784 29909) (785 29907) (786 29920) (787 29959)
  (788 29981) (789 29914) (790 29795) (791 21494) (792 8509) (793 804)
  (794 804) (795 800) (796 800) (797 800) (798 717) (799 323)
  (800 200) (801 202) (802 200) (803 200) (804 172) (805 26) (5533 1)
  (5548 1) (26958 1) (26974 1) (48384 1) (48400 1))
 :distance
 ((0 26807330) (1 5518) (2 941) (3 160056) (4 2) (5 87) (6 25) (8 2)
  (9 2) (10 7) (11 1) (12 22) (13 1) (15 7) (28 1) (30 4) (32 5)
  (35 7) (39 3) (40 1) (42 5) (45 4) (48 2) (49 3) (51 1) (52 1)
  (54 22) (55 7) (82 1) (2762 1) (2772 1) (13478 1) (13485 1)
  (24191 1) (24198 1)))


diff --git a/lisp/subr.el b/lisp/subr.el
index d9df8d1a458..1e9c768fdfe 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -6968,6 +6968,22 @@ internal--format-docstring-line
     (error "Unable to fill string containing newline: %S" string))
   (internal--fill-string-single-line (apply #'format string objects)))
=20
+(defun bytechar--stats ()
+  (unless (hash-table-p internal--bytechar-marker-counts)
+    (setq internal--bytechar-marker-counts (make-hash-table)))
+  (unless (hash-table-p internal--bytechar-distance-counts)
+    (setq internal--bytechar-distance-counts (make-hash-table)))
+  (require 'map)
+  (list (internal--count-markers)
+        :markers
+        (mapcar (lambda (x) (list (car x) (cdr x)))
+             (sort (map-into internal--bytechar-marker-counts 'alist)
+                   #'car-less-than-car))
+        :distance
+        (mapcar (lambda (x) (list (car x) (cdr x)))
+             (sort (map-into internal--bytechar-distance-counts 'alist)
+              #'car-less-than-car))))
+
 (defun json-available-p ()
   "Return non-nil if Emacs has libjansson support."
   (and (fboundp 'json--available-p)
diff --git a/src/marker.c b/src/marker.c
index d220dd82692..623065de3f7 100644
--- a/src/marker.c
+++ b/src/marker.c
@@ -133,6 +133,28 @@ CHECK_MARKER (Lisp_Object x)
   CHECK_TYPE (MARKERP (x), Qmarkerp, x);
 }
=20
+static void
+bytechar_stats (int marker_count, ptrdiff_t distance)
+{
+  if (HASH_TABLE_P (bytechar_marker_counts))
+    {
+      Lisp_Object key =3D make_fixnum (marker_count);
+      Lisp_Object oldcount =3D Fgethash (key, bytechar_marker_counts, Qnil=
);
+      Lisp_Object newcount
+	=3D make_fixnum (FIXNUMP (oldcount) ? 1 + XFIXNUM (oldcount) : 1);
+      Fputhash (key, newcount, bytechar_marker_counts);
+    }
+
+  if (HASH_TABLE_P (bytechar_distance_counts))
+    {
+      Lisp_Object key =3D make_fixnum (distance / 100);
+      Lisp_Object oldcount =3D Fgethash (key, bytechar_distance_counts, Qn=
il);
+      Lisp_Object newcount
+	=3D make_fixnum (FIXNUMP (oldcount) ? 1 + XFIXNUM (oldcount) : 1);
+      Fputhash (key, newcount, bytechar_distance_counts);
+    }
+}
+
 /* When converting bytes from/to chars, we look through the list of
    markers to try and find a good starting point (since markers keep
    track of both bytepos and charpos at the same time).
@@ -164,6 +186,7 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t cha=
rpos)
   ptrdiff_t best_above, best_above_byte;
   ptrdiff_t best_below, best_below_byte;
   ptrdiff_t distance =3D BYTECHAR_DISTANCE_INITIAL;
+  int marker_count =3D 0;
=20
   eassert (BUF_BEG (b) <=3D charpos && charpos <=3D BUF_Z (b));
=20
@@ -198,6 +221,7 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t cha=
rpos)
=20
   for (tail =3D BUF_MARKERS (b); tail; tail =3D tail->next)
     {
+      marker_count++;
       CONSIDER (tail->charpos, tail->bytepos);
=20
       /* If we are down to a range of 50 chars,
@@ -215,6 +239,10 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t ch=
arpos)
      Scan, counting characters, from whichever one is closer.  */
=20
   eassert (best_below <=3D charpos && charpos <=3D best_above);
+  if (!NILP (bytechar_marker_counts))
+    bytechar_stats (marker_count,
+		    min (charpos - best_below, best_above - charpos));
+
   if (charpos - best_below < best_above - charpos)
     {
       bool record =3D charpos - best_below > 5000;
@@ -321,6 +349,7 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t byt=
epos)
   ptrdiff_t best_above, best_above_byte;
   ptrdiff_t best_below, best_below_byte;
   ptrdiff_t distance =3D BYTECHAR_DISTANCE_INITIAL;
+  int marker_count =3D 0;
=20
   eassert (BUF_BEG_BYTE (b) <=3D bytepos && bytepos <=3D BUF_Z_BYTE (b));
=20
@@ -350,6 +379,7 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t byt=
epos)
=20
   for (tail =3D BUF_MARKERS (b); tail; tail =3D tail->next)
     {
+      marker_count++;
       CONSIDER (tail->bytepos, tail->charpos);
=20
       /* If we are down to a range of 50 chars,
@@ -365,6 +395,9 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t byt=
epos)
   /* We get here if we did not exactly hit one of the known places.
      We have one known above and one known below.
      Scan, counting characters, from whichever one is closer.  */
+  if (!NILP (bytechar_marker_counts))
+    bytechar_stats (marker_count,
+		    min (bytepos - best_below_byte, best_above_byte - bytepos));
=20
   if (bytepos - best_below_byte < best_above_byte - bytepos)
     {
@@ -759,22 +792,23 @@ DEFUN ("set-marker-insertion-type", Fset_marker_inser=
tion_type,
   return type;
 }
=20
-#ifdef MARKER_DEBUG
-
 /* For debugging -- count the markers in buffer BUF.  */
=20
-int
-count_markers (struct buffer *buf)
+DEFUN ("internal--count-markers", Fcount_markers, Scount_markers, 0, 0, 0,
+       doc: /* Return the number of markers in the current buffer.  */)
+  (void)
 {
   int total =3D 0;
   struct Lisp_Marker *tail;
=20
-  for (tail =3D BUF_MARKERS (buf); tail; tail =3D tail->next)
+  for (tail =3D BUF_MARKERS (current_buffer); tail; tail =3D tail->next)
     total++;
=20
-  return total;
+  return make_fixnum (total);
 }
=20
+#ifdef MARKER_DEBUG
+
 /* For debugging -- recompute the bytepos corresponding
    to CHARPOS in the simplest, most reliable way.  */
=20
@@ -804,4 +838,18 @@ syms_of_marker (void)
   defsubr (&Scopy_marker);
   defsubr (&Smarker_insertion_type);
   defsubr (&Sset_marker_insertion_type);
+  defsubr (&Scount_markers);
+
+  DEFVAR_LISP ("internal--bytechar-marker-counts",
+	       bytechar_marker_counts, doc: /* Hihi */);
+  bytechar_marker_counts =3D Qnil;
+
+  DEFVAR_LISP ("internal--bytechar-distance-counts",
+	       bytechar_distance_counts, doc: /* Hoho */);
+  bytechar_distance_counts =3D Qnil;
+
+  DEFVAR_INT ("internal--bytechar-distance-increment",
+              bytechar_distance_increment,
+              doc: /* Haha */);
+  bytechar_distance_increment =3D 50;
 }

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Mitchell <mitchellahren@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Jun 2024 03:56:02 +0000
Resent-Message-ID: <handler.71644.B71644.171937413029002 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Ihor Radchenko <yantar92@HIDDEN>, monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171937413029002
          (code B ref 71644); Wed, 26 Jun 2024 03:56:02 +0000
Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 03:55:30 +0000
Received: from localhost ([127.0.0.1]:37893 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMJkn-0007Xi-Ls
	for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 23:55:29 -0400
Received: from mail-ed1-f54.google.com ([209.85.208.54]:45146)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mitchellahren@HIDDEN>) id 1sMJkl-0007XV-Gp
 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 23:55:28 -0400
Received: by mail-ed1-f54.google.com with SMTP id
 4fb4d7f45d1cf-57d1679ee83so6809986a12.2
 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 20:55:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719374059; x=1719978859; 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=YMXsh1+ogi/369VcBAnmBG3nxkbr45b3YDzSvGl1ahQ=;
 b=gGBH+ok84iQwDPcQPqz64GfeGP3r2srCQP55bS4s8xZt6qn4Ul/6W3zISF7z+rVa6K
 RBftciiz/Ou8GtccobXsrMzUjhZhAG1NT6pZDDby9vfiL7glmFSct4n9oNRd6ofnHwJ2
 PizrsPvfTwvSTKPSq5VZaEhaFx6kVrp3r7mTeC8RhzfNmmu3U4D5V8GE0wgMbOtdyo1c
 9yypcQnJpUCRM8FrtmauXzWlchNvZaZiglP1HAe2fMt7y6RudxbeDaVcM9weYr/yHg6Z
 Hlp0kEQus2tdcL7D2b22Tp9NWefvzKM3jEEwCG77SnTbnEEO1THi5HCqqxhOao/ye4F3
 ADlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719374059; x=1719978859;
 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=YMXsh1+ogi/369VcBAnmBG3nxkbr45b3YDzSvGl1ahQ=;
 b=nDeErUGmGO9CG59DEbl9aghMf9kX44p2IK67UYYz67+cV3eG/lLYzPvYczoNF9O2IT
 YdNQ3CyKJs82a7dck0QWQFkLmCX9zO+Ci2vTFKuEOXt6XpsRBChd3ebM6SDl8wF3L9SR
 Pge3G2N/gAEC1LmJG6f4ffrfIcNXfwKcQKMPLSDYqCbkJUKuTLWWBtxRl7t2rc36cQGm
 JvDceVMe/HyLQaJpulLvXRF67VHhZgUkh/xruPInjGd4/QMAj8gCW0XGT64zYzRqzVQ2
 /qK6B2NKLAeBtHY3A+6zx6OklEaicSUr6iVYjp4g/sqyJ5xLCsUtGkIAdLSBnqILYhGl
 Qosw==
X-Forwarded-Encrypted: i=1;
 AJvYcCUNebQaZgaRQtoSeAmvXICq5CVHi/WB3RDZI4L4dD+TtIOCloyeKBbMc0vDJNEbWnNM21ejSbCFeKiotIr6SksX0fxP2zU=
X-Gm-Message-State: AOJu0YzcNNNmfbdzxR5I2gXmpXIKJtn4L2K5TnnFbI43NpT2Y1P/Mgnc
 vJdIQjbhKg2XznIuYuVPD2prMCjdyUg1reVR3v7balX4hcimvFRBIy/lS5dO9ZflLFUXirimYU6
 6jewk8Z4vggzyyKUxnNsLDxgljgw=
X-Google-Smtp-Source: AGHT+IEtjaxsAKbjMJh4SguLy8BOJo3muAwaDuuwB1Os+6qfGRavrS5DCPCW3v8QH8QqCJ0E8/oRfk2Ars/7SB9AGcM=
X-Received: by 2002:a50:d795:0:b0:57c:c019:a9f6 with SMTP id
 4fb4d7f45d1cf-57d457f60f9mr6988922a12.32.1719374059188; Tue, 25 Jun 2024
 20:54:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> <87frt15dya.fsf@localhost>
 <86jzid9lbj.fsf@HIDDEN>
In-Reply-To: <86jzid9lbj.fsf@HIDDEN>
From: Mitchell <mitchellahren@HIDDEN>
Date: Tue, 25 Jun 2024 21:53:42 -0600
Message-ID: <CAOQwW=bYKO7qbf176EtH1VY5y-5T+orTGNtPWgqWW4o5Sn8KLQ@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000008b821061bc2f865"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000008b821061bc2f865
Content-Type: text/plain; charset="UTF-8"

 > > Eli Zaretskii <eliz@HIDDEN> writes:
> >
> > > ...  So if you could come up with a change to try on
> > > top of Org 9.6 that would change it back to use overlays for folding,
> > > we could try that and see if the slowdown goes away, and take it from
> > > there.
> >
> > (setq org-fold-core-style 'overlays) ; before Org is loaded
>
>    Thanks.  Mitchell and Stefan, can you try this?

I tested setting org-fold-core-style to 'overlays before loading org and
unfortunately it did not help the slowness in the test org buffer. These
are the two lines I tried in separate tests:

(setq org-fold-core-style 'overlays)
(customize-set-variable 'org-fold-core-style 'overlays)

--00000000000008b821061bc2f865
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote">
&gt;=20

&gt; Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>&gt;=
 writes:<br>
&gt;=20

&gt;<br>
&gt;=20

&gt; &gt; ...=C2=A0 So if you could come up with a change to try on<br>
&gt;=20

&gt; &gt; top of Org 9.6 that would change it back to use overlays for fold=
ing,<br>
&gt;=20

&gt; &gt; we could try that and see if the slowdown goes away, and take it =
from<br>
&gt;=20

&gt; &gt; there.<br>
&gt;=20

&gt;<br>
&gt;=20

&gt; (setq org-fold-core-style &#39;overlays) ; before Org is loaded<br>
&gt;=20

<br>
&gt;=C2=A0 =C2=A0 Thanks.=C2=A0 Mitchell and Stefan, can you try this?<div>=
=C2=A0</div><div>I tested setting=20
org-fold-core-style to &#39;overlays before loading org and unfortunately i=
t did not help the slowness in the test org buffer. These are the two lines=
 I tried in separate tests:<br></div><div><br></div><div>(setq org-fold-cor=
e-style &#39;overlays)</div><div>(customize-set-variable &#39;org-fold-core=
-style &#39;overlays)</div></div></div>

--00000000000008b821061bc2f865--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Jun 2024 11:42:01 +0000
Resent-Message-ID: <handler.71644.B71644.171940208022800 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171940208022800
          (code B ref 71644); Wed, 26 Jun 2024 11:42:01 +0000
Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 11:41:20 +0000
Received: from localhost ([127.0.0.1]:38686 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMR1c-0005vf-8q
	for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 07:41:20 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55684)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sMR1a-0005vS-4P
 for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 07:41:19 -0400
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 <eliz@HIDDEN>)
 id 1sMR1R-0005Fq-IO; Wed, 26 Jun 2024 07:41:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=0G7gk4U4H8PhiIJsiM1TFVYg/3UKEOvFBv+P+vcn66s=; b=hmgED/e4SdkJ
 LfL0de3DPvlqnzj9Nsi40Yl0LIEXlyttllVxwJ6ReTiJOqlruwR/h+IblGlHHp5iu/QVIL53nAgUY
 H7z7CdmswcWT/EPufNagoJAhRztEF0GGCIh4QJmcOBZMuMZdCd+mJLmF2FFTpeL9+FhLcQayPdDEj
 zjYWzcspm/IynxVIFZeEG77//Yk5kyn05HhY9NcBmcldqEuncWDVIvg5joDzfWh/8BM1G4jUXVS1B
 5RK8kYrLGaht8egmyv5Lh0rOkJCOOOkhlGB6bjQoTq4Bgvgmy2HR7RObPTfXrPnHf/Tl+Uu9J9J5o
 YB2B+4r/s5OVoyBo8T9L2g==;
Date: Wed, 26 Jun 2024 14:41:06 +0300
Message-Id: <861q4k9bjh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Tue, 25 Jun 2024 16:54:44 -0400)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Mitchell <mitchellahren@HIDDEN>,  Eli Zaretskii <eliz@HIDDEN>,
>   71644 <at> debbugs.gnu.org
> Date: Tue, 25 Jun 2024 16:54:44 -0400
> 
> I instrumented the bytes<->chars routines to try and keep track of what
> happens there.  This gives me a histogram showing how many times the
> conversion routines consulted N markers as well as another histogram
> telling me how many times those routines scanned between M*100B and
> (M+1)*100B of text.
> Oh and it gives me the number of markers in the buffer as well (the
> histogram is not buffer-local, but there's basically only one buffer in
> that session).
> 
> The result are below (followed by the actual code).
> There are several odd things in there:
> 
> - The markers histogram is weirdly flat.
> - The markers histogram seems to have a threshold around 800
>   I can't explain.  It seems directly related to the buffer size, tho:
>   with a file half the size, I get half as many markers (40k) and
>   a threshold in the histogram around 400.
> - The number of times we consider exactly 1 marker is probably "too
>   high" because the C code happens to look at the first marker before
>   checking if it's necessary.

The fact that it's related to buffer size is probably because your
test buffer is basically N >> 1 repetitions of the same pattern, so
whatever Org does it does that N times, where N is directly
proportional to the buffer size.

Questions:

How many markers are there in this buffer during the experiment where
you produced the histogram you've posted?  My guess is 48400 or
thereabouts?

Also, what were the buffer positions where you tried your editing
operations?  In particular, where those positions distributed evenly
over the buffer?

And questions to Ihor: what are the reasons Org creates these markers?
In particular, is there any way to know or guess whether these markers
will be distributed more-or-less evenly over the buffer text, or
clustered near some specific positions?  Also, does Org move these
markers frequently, or do they stay put once created?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Jun 2024 12:35:02 +0000
Resent-Message-ID: <handler.71644.B71644.171940527027750 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: mitchellahren@HIDDEN, Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171940527027750
          (code B ref 71644); Wed, 26 Jun 2024 12:35:02 +0000
Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 12:34:30 +0000
Received: from localhost ([127.0.0.1]:38739 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMRr4-0007DW-33
	for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:34:30 -0400
Received: from mout02.posteo.de ([185.67.36.66]:54589)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sMRr2-0007DB-80
 for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:34:28 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 43AD7240103
 for <71644 <at> debbugs.gnu.org>; Wed, 26 Jun 2024 14:34:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1719405259; bh=+uMHnMZivwfdkeQCyklvXEWVHUuHHxBmQJaD4ZJ+FQ0=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=X5wb+jrnn5vy+NDblylJtTRHrFGPtQY7Za6+OxMSErxabjHnJA5CfH8hWchbLbIi0
 hvfFLFksX37Ra64vPAEstfHZP87e+ZVNhkJX4kSn9ILIrxhW7pqrj/dEkenRV6u9Ve
 b9S/nB0iXaMqFAQEeXCY2BezC9pLNNyC3X/NXI5iYQcf1OeKtnPYEBucrNBphbFE/s
 C4TUB9obZpdJkzro0DIGoF39caPkkzgGKWd2RIvR+bXOIbusYuJ3b9tM91YDMWQ7LS
 P2Q8Gpkz8VISTP+TsDBauTnHey3skkYtOMUUFqctrLb+rB6CEZGlNYI4i06VO0PPIO
 ltyCzDd94ImbQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W8Ljh1rKrz9rxK;
 Wed, 26 Jun 2024 14:34:16 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <861q4k9bjh.fsf@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> <861q4k9bjh.fsf@HIDDEN>
Date: Wed, 26 Jun 2024 12:35:55 +0000
Message-ID: <87zfr7lw44.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

> And questions to Ihor: what are the reasons Org creates these markers?
> In particular, is there any way to know or guess whether these markers
> will be distributed more-or-less evenly over the buffer text, or
> clustered near some specific positions?  Also, does Org move these
> markers frequently, or do they stay put once created?

In this particular case, with the reproducer we are using here, Org does
not create markers. `councel-outline' does - for every headline in
buffer with marker pointing to the beginning of each headline.
These markers are distributed as headlines do.

Org mode may also create markers in some scenarios. Also at headlines,
but not necessarily _all_ headlines. org-agenda creates markers for
every headline that is displayed in agenda (matches agenda search
criterion). org-refile creates markers for each top level heading (by
default). org-goto creates markers for each heading down to level 5.

Org mode does not move these markers frequently, except markers created
by agenda, when a heading is killed/yanked via
org-cut-special/org-paste-subtree or org-refile commands.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Jun 2024 12:42:01 +0000
Resent-Message-ID: <handler.71644.B71644.171940568428394 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Mitchell <mitchellahren@HIDDEN>
Cc: yantar92@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.171940568428394
          (code B ref 71644); Wed, 26 Jun 2024 12:42:01 +0000
Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 12:41:24 +0000
Received: from localhost ([127.0.0.1]:38749 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMRxk-0007Nu-GZ
	for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:41:24 -0400
Received: from eggs.gnu.org ([209.51.188.92]:42826)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sMRxi-0007Nb-6v
 for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:41:23 -0400
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 <eliz@HIDDEN>)
 id 1sMRxa-0000MA-Jo; Wed, 26 Jun 2024 08:41:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=yfGduc2t0YktytLOhaxSlsEAvr7RyAsw9FKmHom6ocU=; b=iJvugcLjP8nP
 785XmT9BAnOWta+akSXUS20tPPEndzqJKr3xqeC5ri2p1y6dL/Sapzv+o9Gnun7EfeIysXKbYL1Ul
 Oca9sqp9qgwCQTuDHTBtyVwuwFjcN4gNx14BjEFKQvQ6kISDyxulMG3bmc0ItqEJ5+dxtxd96FQEX
 wRmTM6/PjhRlduc3YIpDyrcqUPRKcEgY5MUy3+2Pc4xFmKVNNP1QW29jQC3Sw5m9rP13/y7VnmMkA
 meiq0G3wZ4bbHP8gT/8EESK6E6QXZKGGUwY9YklCX6LGOYwNGpY5EOu42Z0reyV0nIoWNRFMjZpkh
 sYxHHcwoG1UvGMACeW8Vfw==;
Date: Wed, 26 Jun 2024 15:41:11 +0300
Message-Id: <86tthf98rc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAOQwW=bYKO7qbf176EtH1VY5y-5T+orTGNtPWgqWW4o5Sn8KLQ@HIDDEN>
 (message from Mitchell on Tue, 25 Jun 2024 21:53:42 -0600)
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> <87frt15dya.fsf@localhost>
 <86jzid9lbj.fsf@HIDDEN>
 <CAOQwW=bYKO7qbf176EtH1VY5y-5T+orTGNtPWgqWW4o5Sn8KLQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Mitchell <mitchellahren@HIDDEN>
> Date: Tue, 25 Jun 2024 21:53:42 -0600
> Cc: Ihor Radchenko <yantar92@HIDDEN>, monnier@HIDDEN, 71644 <at> debbugs.gnu.org
> 
> > > Eli Zaretskii <eliz@HIDDEN> writes:
> > >
> > > > ...  So if you could come up with a change to try on
> > > > top of Org 9.6 that would change it back to use overlays for folding,
> > > > we could try that and see if the slowdown goes away, and take it from
> > > > there.
> > >
> > > (setq org-fold-core-style 'overlays) ; before Org is loaded
> > 
> >    Thanks.  Mitchell and Stefan, can you try this?
>  
> I tested setting org-fold-core-style to 'overlays before loading org and unfortunately it did not help the
> slowness in the test org buffer. These are the two lines I tried in separate tests:
> 
> (setq org-fold-core-style 'overlays)
> (customize-set-variable 'org-fold-core-style 'overlays)

Thanks, I guess it means this theory eats dust.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Jun 2024 13:31:01 +0000
Resent-Message-ID: <handler.71644.B71644.17194086381344 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17194086381344
          (code B ref 71644); Wed, 26 Jun 2024 13:31:01 +0000
Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 13:30:38 +0000
Received: from localhost ([127.0.0.1]:38812 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMSjN-0000LX-Uk
	for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:30:38 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16531)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sMSjM-0000L8-F1
 for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:30:36 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 76589441754;
 Wed, 26 Jun 2024 09:30:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719408626;
 bh=4FAkVjSxhbukgFWKSw6JX8VN7l67fwdgcna8OGgEDp0=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=SsxTcke7xaYIklB9E4qymh5Zb1+RXkuxvuxOh7s0bjgaPbo09XwkgvqkvcZaI302x
 uvgQZqVrDxYorwy7yml7Un3gP0stj8LgHehnqQ4WRhtBmbz5a8umivavq2ZLzYZ0Hm
 VB6Ls1xFzTrF1vCMZeQNanbF3VH/viR48GjuanAXOXhr0xJh+pZPOo0W1AsBEbdf90
 Yq9kdDRoGKP/L5uGQlHuzBbytrGvo9fSfx9qvyytsU/PvSUoANki5Tn8OSB0K1ORT7
 dUjagaKzsKaDMUjq6lP5Wy5Rh1Y0esSCQttinRp7s1AbP6gb/+hA1EtKngmXdCfXAj
 ctFvX78s+h1Yg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BCDA0440EE8;
 Wed, 26 Jun 2024 09:30:26 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8953C1207CF;
 Wed, 26 Jun 2024 09:30:26 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <861q4k9bjh.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 26 Jun
 2024 14:41:06 +0300")
Message-ID: <jwvtthfzvhm.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> <861q4k9bjh.fsf@HIDDEN>
Date: Wed, 26 Jun 2024 09:30:25 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.083 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> - The markers histogram is weirdly flat.
>> - The markers histogram seems to have a threshold around 800
>>   I can't explain.  It seems directly related to the buffer size, tho:
>>   with a file half the size, I get half as many markers (40k) and
>>   a threshold in the histogram around 400.
>> - The number of times we consider exactly 1 marker is probably "too
>>   high" because the C code happens to look at the first marker before
>>   checking if it's necessary.
>
> The fact that it's related to buffer size is probably because your
> test buffer is basically N >> 1 repetitions of the same pattern, so
> whatever Org does it does that N times, where N is directly
> proportional to the buffer size.

Yes, definitely.  The threshold is at about N/100 where N is the number
of markers/headings.  But why 100?

> How many markers are there in this buffer during the experiment where
> you produced the histogram you've posted?  My guess is 48400 or
> thereabouts?

It's the first number in the list (the one before `:markers`): 80044

> Also, what were the buffer positions where you tried your editing
> operations?  In particular, where those positions distributed evenly
> over the buffer?

I focused on edits on the first copy and on the last copy.

> And questions to Ihor: what are the reasons Org creates these markers?
> In particular, is there any way to know or guess whether these markers
> will be distributed more-or-less evenly over the buffer text, or
> clustered near some specific positions?  Also, does Org move these
> markers frequently, or do they stay put once created?

They're created by `consult-outline` rather than by Org.
There's one marker per heading, AFAICT, and so they're very
evenly spread (and presumably ordered last-to-first in the `markers`
list).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Jun 2024 13:48:02 +0000
Resent-Message-ID: <handler.71644.B71644.17194096622898 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71644
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
Received: via spool by 71644-submit <at> debbugs.gnu.org id=B71644.17194096622898
          (code B ref 71644); Wed, 26 Jun 2024 13:48:02 +0000
Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 13:47:42 +0000
Received: from localhost ([127.0.0.1]:38840 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sMSzt-0000kg-M4
	for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:47:41 -0400
Received: from mout02.posteo.de ([185.67.36.66]:35609)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1sMSzs-0000kT-8h
 for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:47:40 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 1A98C240103
 for <71644 <at> debbugs.gnu.org>; Wed, 26 Jun 2024 15:47:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1719409652; bh=9/WoiVtPKig6J9HtQph+yQG8sHN0nZ0Sf1etSMHMoek=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=BcpTa/PInL29nToVMDz8q1MYHfv/ztzDRhDeW1rOlVTFgbRfvFGjWUbcyLI+4Wd7n
 z+nMIBGyYdDWh12WX4zXhg8Cnfs6Zk+e94Ui0WUvNmoI34tmUl5klvOhc1VU3w/lmv
 aA0HNWz+WIuwzLAND2bfapv9zP3g9klB23lR8579mmqbusAKGKlHXBp85u6ZdwZyD9
 w/ORdwI0HZGv2kr1RmxJag7pcvoz3wIeER7/hU8jrrCiTlpZlVTrSFBGzAE/1ZCPlE
 XCXfHmPXZNP/Y4sDsP1NsipeNEACnQJ8fCpMyKWza8YWQ8rbFp7o2FMkcg5QCI9U1C
 zNO8PclU2HfkQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4W8NLB5s6Mz9rxB;
 Wed, 26 Jun 2024 15:47:30 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvtthfzvhm.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
 <86ed8tozub.fsf@HIDDEN>
 <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
 <86jzijmo5a.fsf@HIDDEN>
 <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
 <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
 <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
 <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> <861q4k9bjh.fsf@HIDDEN>
 <jwvtthfzvhm.fsf-monnier+emacs@HIDDEN>
Date: Wed, 26 Jun 2024 13:49:09 +0000
Message-ID: <87r0cjddbe.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

> Yes, definitely.  The threshold is at about N/100 where N is the number
> of markers/headings.  But why 100?

Maybe because

bytepos - best_below_byte > 5000
and distance += BYTECHAR_DISTANCE_INCREMENT;
(BYTECHAR_DISTANCE_INCREMENT = 50)

Then, (/ 5000 50) ; -> 100.

In other words,
for (tail = BUF_MARKERS (b); tail; tail = tail->next)
loop is roughly bound to (min number-of-markers 100)-ish
repetitions. So, once the number of markers exceeds 100, there is no
more scaling with the marker number.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Last modified: Wed, 26 Jun 2024 14:00:02 UTC

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