Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extreme performance problems from sp--post-self-insert-hook-handler #1209

Open
Addlai opened this issue May 27, 2024 · 3 comments
Open

Extreme performance problems from sp--post-self-insert-hook-handler #1209

Addlai opened this issue May 27, 2024 · 3 comments

Comments

@Addlai
Copy link

Addlai commented May 27, 2024

Expected behavior

I installed smartparens, with the expectation that it would assist in routing parenthesis matching and sexp navigation without any noticeable perforannce hit.

Actual behavior

Very severe sluggishness in certain situations. For instance, inside an org-mode buffer, in an emacs-lisp src block, inside a string (such as "This is a string").
Note that editing the lisp code with org-edit-special doesn't have the problem.

The Emacs profiler reported over 1.2 billion calls to the org-self-insert-command, which in turn was calling sp--post-self-insert-hook-handler. (This is in the space of about 5 seconds writing just a few characters.)

The value of post-self-insert-hook is (sp--post-self-insert-hook-handler t).

This suggests that there is perhaps some kind of recursive loop taking place with smartparens somehow triggering the post-self-insert-hook.

Steps to reproduce the problem

Write a string inside an emacs-lisp src block in an org-mode buffer.

Backtraces if necessary (M-x toggle-debug-on-error)

Environment & version information

In recent enough smartparens you can call M-x sp-describe-system to generate this report. Please fill manually what we could not detect automatically. Edit the output as you see fit to protect your privacy.

  • smartparens version: 20240415.2253
  • Active major-mode: org-mode
  • Emacs version (M-x emacs-version): "GNU Emacs 29.3 (build 1, aarch64-apple-darwin23.4.0, NS appkit-2487.50 Version 14.4.1 (Build 23E224)) of 2024-04-19"
  • Spacemacs/Evil/Other starterkit (specify which)/Vanilla: Vanilla
  • OS: macOS Sonoma 14.5
@Fuco1
Copy link
Owner

Fuco1 commented May 28, 2024

Thanks for the report. There are some weird edge cases concerning org mode and source code blocks. 1.2 billion seems a bit excessive in the span of 5 seconds so I think your idea sounds about right, there must be something looping (maybe recursion would blow the stack first, but could also be in principle, you can check the value of max-lisp-eval-depth for the max recursive depth your Emacs supports).

@Fuco1 Fuco1 moved this from To triage to Backlog in Triage May 28, 2024
@7ocb
Copy link

7ocb commented Sep 16, 2024

I also see performance issues coming from sp--post-self-insert-hook-handler. Not sure if this generally the same case, but also relies to org mode (note that there is no code blocks in org file).

Steps to reproduce:

  1. run emacs: emacs -q

  2. exec initialization:

(require 'package)
(package-initialize)
(require 'smartparens)
(require 'smartparens-config)
(smartparens-global-mode)
  1. open attached file (it has initialization commands at the beginning for convenience) (attached as "txt" so github does not complain on unsupported type): test-slow-sp.org.txt

  2. search for heading named "this is heading to do input in"

  3. try to type something there

  4. observe how sluggish input is

Profiler shows that 50% of time spent in the sp--post-self-insert-hook-handler function (and another 25% in the GC, may be related?).

@Addlai
Copy link
Author

Addlai commented Sep 26, 2024

@7ocb This sounds similar to what I'm experiencing. If I leave smartparens on, I'm having calls to the GC every couple of seconds when editing org files, even outside code blocks. The very specific situation I cited was just to have a concrete, particularly severe situation to test for debugging purposes. But yes, org-mode and smartparens aren't getting along well at all here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Backlog
Development

No branches or pull requests

3 participants