smartparens icon indicating copy to clipboard operation
smartparens copied to clipboard

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

Open Addlai opened this issue 1 year ago • 3 comments

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

Addlai avatar May 27 '24 23:05 Addlai

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 avatar May 28 '24 12:05 Fuco1

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

7ocb avatar Sep 16 '24 07:09 7ocb

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

Addlai avatar Sep 26 '24 22:09 Addlai