Package: emacs;
To reply to this bug, email your comments to 77620 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#77620; Package emacs.
(Mon, 07 Apr 2025 21:50:02 GMT) Full text and rfc822 format available.JD Smith <jdtsmith <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Mon, 07 Apr 2025 21:50:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: JD Smith <jdtsmith <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Subject: thingatpt can be incredibly slow in python-mode buffers Date: Mon, 7 Apr 2025 17:48:49 -0400
[Message part 1 (text/plain, inline)]
As discussed in Bug#77588: > (/ (car (benchmark-run 10 (thing-at-point 'sexp))) 10) Try this test at the start of L8817 in this file (no eglot needed; either python-mode or python-ts-mode is fine, as both show the same issue): https://raw.githubusercontent.com/matplotlib/matplotlib/refs/heads/main/lib/matplotlib/axes/_axes.py https://raw.githubusercontent.com/matplotlib/matplotlib/refs/heads/main/lib/matplotlib/axes/_axes.py _axes Text Document · 353 KB In #77588 this was shown to lead to long intermittent pauses with eglot in large python buffers, but the issue is more general for any packages using thingatpt in python buffers.
[Message part 2 (text/html, inline)]
[preview.png (image/png, inline)]
bug-gnu-emacs <at> gnu.org:bug#77620; Package emacs.
(Tue, 08 Apr 2025 10:53:01 GMT) Full text and rfc822 format available.Message #8 received at 77620 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: JD Smith <jdtsmith <at> gmail.com>, kobarity <kobarity <at> gmail.com> Cc: 77620 <at> debbugs.gnu.org Subject: Re: bug#77620: thingatpt can be incredibly slow in python-mode buffers Date: Tue, 08 Apr 2025 13:52:44 +0300
> From: JD Smith <jdtsmith <at> gmail.com>
> Date: Mon, 7 Apr 2025 17:48:49 -0400
>
> > (/ (car (benchmark-run 10 (thing-at-point 'sexp))) 10)
>
>
> Try this test at the start of L8817 in this file (no eglot needed; either python-mode or python-ts-mode is fine, as both show the same issue):
>
> https://raw.githubusercontent.com/matplotlib/matplotlib/refs/heads/main/lib/matplotlib/axes/_axes.py
> https://raw.githubusercontent.com/matplotlib/matplotlib/refs/heads/main/lib/matplotlib/axes/_axes.py
> _axes
> Text Document · 353 KB
>
> In #77588 this was shown to lead to long intermittent pauses with eglot in large python buffers, but the issue is more general for any packages using thingatpt in python buffers.
The Lisp profile, which seems to point to the likely culprit, is
below.
Maybe kobarity (CC'ed) will have some ideas or suggestions.
345 89% - ...
343 89% - cond
343 89% - let
343 89% - condition-case
343 89% - progn
343 89% - save-excursion
173 44% - funcall
173 44% - thing-at-point--end-of-sexp
173 44% - let
173 44% - if
173 44% - condition-case
173 44% - forward-sexp
173 44% - python-nav-forward-sexp
173 44% - python-nav--forward-sexp
173 44% - python-info-statement-ends-block-p
173 44% - python-nav-end-of-block
96 24% - python-nav-end-of-statement
69 17% - syntax-ppss
67 17% parse-partial-sexp
27 7% - python-info-line-ends-backslash-p
27 7% - syntax-ppss
27 7% parse-partial-sexp
76 19% - python-nav-beginning-of-block
76 19% - python-nav-backward-block
76 19% - python-nav-forward-block
75 19% - python-syntax-context-type
75 19% - syntax-ppss
74 19% parse-partial-sexp
1 0% - python-nav-beginning-of-statement
1 0% point-marker
1 0% current-indentation
170 44% - let
170 44% - if
170 44% - funcall
170 44% - thing-at-point--beginning-of-sexp
170 44% - let
170 44% - if
170 44% - forward-sexp
170 44% - python-nav-forward-sexp
170 44% - python-nav--forward-sexp
170 44% - python-info-statement-ends-block-p
170 44% - python-nav-end-of-block
95 24% - python-nav-end-of-statement
63 16% - syntax-ppss
62 16% parse-partial-sexp
31 8% - python-info-line-ends-backslash-p
31 8% - syntax-ppss
30 7% parse-partial-sexp
1 0% re-search-forward
75 19% - python-nav-beginning-of-block
75 19% - python-nav-backward-block
75 19% - python-nav-forward-block
72 18% - python-syntax-context-type
72 18% - syntax-ppss
71 18% parse-partial-sexp
2 0% re-search-backward
1 0% - python-nav-beginning-of-statement
1 0% - python-info-line-ends-backslash-p
1 0% - syntax-ppss
1 0% syntax-ppss--data
2 0% - python-shell-get-process
2 0% - python-shell-get-buffer
2 0% - seq-some
2 0% + seq-do
32 8% Automatic GC
6 1% - command-execute
6 1% - call-interactively
6 1% - byte-code
6 1% - read-extended-command
6 1% - read-extended-command-1
6 1% - completing-read
6 1% - completing-read-default
6 1% - read-from-minibuffer
1 0% redisplay_internal (C function)
2 0% redisplay_internal (C function)
bug-gnu-emacs <at> gnu.org:bug#77620; Package emacs.
(Wed, 09 Apr 2025 15:34:02 GMT) Full text and rfc822 format available.Message #11 received at 77620 <at> debbugs.gnu.org (full text, mbox):
From: kobarity <kobarity <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 77620 <at> debbugs.gnu.org, JD Smith <jdtsmith <at> gmail.com> Subject: Re: bug#77620: thingatpt can be incredibly slow in python-mode buffers Date: Thu, 10 Apr 2025 00:33:03 +0900
Eli Zaretskii wrote: > > > From: JD Smith <jdtsmith <at> gmail.com> > > Date: Mon, 7 Apr 2025 17:48:49 -0400 > > > > > (/ (car (benchmark-run 10 (thing-at-point 'sexp))) 10) > > > > > > Try this test at the start of L8817 in this file (no eglot needed; either python-mode or python-ts-mode is fine, as both show the same issue): > > > > https://raw.githubusercontent.com/matplotlib/matplotlib/refs/heads/main/lib/matplotlib/axes/_axes.py > > https://raw.githubusercontent.com/matplotlib/matplotlib/refs/heads/main/lib/matplotlib/axes/_axes.py > > _axes > > Text Document · 353 KB > > > > In #77588 this was shown to lead to long intermittent pauses with eglot in large python buffers, but the issue is more general for any packages using thingatpt in python buffers. > > The Lisp profile, which seems to point to the likely culprit, is > below. > > Maybe kobarity (CC'ed) will have some ideas or suggestions. > > 345 89% - ... > 343 89% - cond > 343 89% - let > 343 89% - condition-case > 343 89% - progn > 343 89% - save-excursion > 173 44% - funcall > 173 44% - thing-at-point--end-of-sexp > 173 44% - let > 173 44% - if > 173 44% - condition-case > 173 44% - forward-sexp > 173 44% - python-nav-forward-sexp > 173 44% - python-nav--forward-sexp > 173 44% - python-info-statement-ends-block-p > 173 44% - python-nav-end-of-block > 96 24% - python-nav-end-of-statement > 69 17% - syntax-ppss > 67 17% parse-partial-sexp > 27 7% - python-info-line-ends-backslash-p > 27 7% - syntax-ppss > 27 7% parse-partial-sexp > 76 19% - python-nav-beginning-of-block > 76 19% - python-nav-backward-block > 76 19% - python-nav-forward-block > 75 19% - python-syntax-context-type > 75 19% - syntax-ppss > 74 19% parse-partial-sexp > 1 0% - python-nav-beginning-of-statement > 1 0% point-marker > 1 0% current-indentation > 170 44% - let > 170 44% - if > 170 44% - funcall > 170 44% - thing-at-point--beginning-of-sexp > 170 44% - let > 170 44% - if > 170 44% - forward-sexp > 170 44% - python-nav-forward-sexp > 170 44% - python-nav--forward-sexp > 170 44% - python-info-statement-ends-block-p > 170 44% - python-nav-end-of-block > 95 24% - python-nav-end-of-statement > 63 16% - syntax-ppss > 62 16% parse-partial-sexp > 31 8% - python-info-line-ends-backslash-p > 31 8% - syntax-ppss > 30 7% parse-partial-sexp > 1 0% re-search-forward > 75 19% - python-nav-beginning-of-block > 75 19% - python-nav-backward-block > 75 19% - python-nav-forward-block > 72 18% - python-syntax-context-type > 72 18% - syntax-ppss > 71 18% parse-partial-sexp > 2 0% re-search-backward > 1 0% - python-nav-beginning-of-statement > 1 0% - python-info-line-ends-backslash-p > 1 0% - syntax-ppss > 1 0% syntax-ppss--data > 2 0% - python-shell-get-process > 2 0% - python-shell-get-buffer > 2 0% - seq-some > 2 0% + seq-do > 32 8% Automatic GC > 6 1% - command-execute > 6 1% - call-interactively > 6 1% - byte-code > 6 1% - read-extended-command > 6 1% - read-extended-command-1 > 6 1% - completing-read > 6 1% - completing-read-default > 6 1% - read-from-minibuffer > 1 0% redisplay_internal (C function) > 2 0% redisplay_internal (C function) Please give me some time as I'm trying to improve performance.
bug-gnu-emacs <at> gnu.org:bug#77620; Package emacs.
(Wed, 09 Apr 2025 15:53:02 GMT) Full text and rfc822 format available.Message #14 received at 77620 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: kobarity <kobarity <at> gmail.com> Cc: 77620 <at> debbugs.gnu.org, jdtsmith <at> gmail.com Subject: Re: bug#77620: thingatpt can be incredibly slow in python-mode buffers Date: Wed, 09 Apr 2025 18:52:18 +0300
> Date: Thu, 10 Apr 2025 00:33:03 +0900 > From: kobarity <kobarity <at> gmail.com> > Cc: JD Smith <jdtsmith <at> gmail.com>, > 77620 <at> debbugs.gnu.org > > Eli Zaretskii wrote: > > > > > In #77588 this was shown to lead to long intermittent pauses with eglot in large python buffers, but the issue is more general for any packages using thingatpt in python buffers. > > > > The Lisp profile, which seems to point to the likely culprit, is > > below. > > > > Maybe kobarity (CC'ed) will have some ideas or suggestions. > > > > 345 89% - ... > > 343 89% - cond > > 343 89% - let > > 343 89% - condition-case > > 343 89% - progn > > 343 89% - save-excursion > > 173 44% - funcall > > 173 44% - thing-at-point--end-of-sexp > > 173 44% - let > > 173 44% - if > > 173 44% - condition-case > > 173 44% - forward-sexp > > 173 44% - python-nav-forward-sexp > > 173 44% - python-nav--forward-sexp > > 173 44% - python-info-statement-ends-block-p > > 173 44% - python-nav-end-of-block > > 96 24% - python-nav-end-of-statement > > 69 17% - syntax-ppss > > 67 17% parse-partial-sexp > > 27 7% - python-info-line-ends-backslash-p > > 27 7% - syntax-ppss > > 27 7% parse-partial-sexp > > 76 19% - python-nav-beginning-of-block > > 76 19% - python-nav-backward-block > > 76 19% - python-nav-forward-block > > 75 19% - python-syntax-context-type > > 75 19% - syntax-ppss > > 74 19% parse-partial-sexp > > 1 0% - python-nav-beginning-of-statement > > 1 0% point-marker > > 1 0% current-indentation > > 170 44% - let > > 170 44% - if > > 170 44% - funcall > > 170 44% - thing-at-point--beginning-of-sexp > > 170 44% - let > > 170 44% - if > > 170 44% - forward-sexp > > 170 44% - python-nav-forward-sexp > > 170 44% - python-nav--forward-sexp > > 170 44% - python-info-statement-ends-block-p > > 170 44% - python-nav-end-of-block > > 95 24% - python-nav-end-of-statement > > 63 16% - syntax-ppss > > 62 16% parse-partial-sexp > > 31 8% - python-info-line-ends-backslash-p > > 31 8% - syntax-ppss > > 30 7% parse-partial-sexp > > 1 0% re-search-forward > > 75 19% - python-nav-beginning-of-block > > 75 19% - python-nav-backward-block > > 75 19% - python-nav-forward-block > > 72 18% - python-syntax-context-type > > 72 18% - syntax-ppss > > 71 18% parse-partial-sexp > > 2 0% re-search-backward > > 1 0% - python-nav-beginning-of-statement > > 1 0% - python-info-line-ends-backslash-p > > 1 0% - syntax-ppss > > 1 0% syntax-ppss--data > > 2 0% - python-shell-get-process > > 2 0% - python-shell-get-buffer > > 2 0% - seq-some > > 2 0% + seq-do > > 32 8% Automatic GC > > 6 1% - command-execute > > 6 1% - call-interactively > > 6 1% - byte-code > > 6 1% - read-extended-command > > 6 1% - read-extended-command-1 > > 6 1% - completing-read > > 6 1% - completing-read-default > > 6 1% - read-from-minibuffer > > 1 0% redisplay_internal (C function) > > 2 0% redisplay_internal (C function) > > Please give me some time as I'm trying to improve performance. Sure, there's no rush. TIA.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.