bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23928: 25.0.95; Performance regression observable with smartparens


From: Aaron Jensen
Subject: bug#23928: 25.0.95; Performance regression observable with smartparens
Date: Sun, 10 Jul 2016 15:58:58 +0000

On Sun, Jul 10, 2016 at 7:30 AM Eli Zaretskii <eliz@gnu.org> wrote:
Thanks.

That rings a bell.  The hottest function on these profiles is
sp--looking-back, which calls in a loop sp--looking-at, which does
this:

  (defun sp--looking-at (regexp)
    "Like `looking-at', but always case sensitive."
    (let ((case-fold-search nil))
      (looking-at regexp)))

As you will see from bug#18522, binding case-fold-search can be very
expensive, especially if you have a lot of buffers.  See
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18522#201 for a summary
of the findings there.  It clearly shows in your profile:

                 sp--looking-at                171  12%
                  let                           12   0%

As to why you see a slowdown in Emacs 25, I don't know.  Maybe you
have more buffers crop up there as the session goes on?

Interesting, yes this is possible. I switched to Emacs 25 before I started emacs itself heavily and using window configurations heavily, so it is very likely that I just end up with a large number of buffers and that’s when the slowdown happens.

What is the alternative to binding case-fold-search? Could smartparens just bind it once in a surrounding function? Or is there another way to ensure that `looking-at` is case sensitive?


> One curious thing is that the emacs 24 profile shows all of the builtins (let/if/save-excusion) and the emacs 25 profile does not. Is there something I’m doing wrong that is causing that?

Could it be that in Emacs 24 you loaded the library as a .el file, and
in Emacs 25 as a .elc file?

I suppose this is possible, I had just started emacs 24 and let it install all from elpa/melpa (I’m using spacemacs, so it handled all this for me). Typically it compiles everything, but maybe it hadn’t yet in the session I was running. I have confirmed that if I eval-buffer smartparens.el, I get the more detailed profile. That’s useful, thanks.


> I’ll work on this. It seems possible that it will be very hard to track down given the nature—the performance isn’t *always* bad, it just becomes bad at some point in the session.

When it becomes bad, count the number of buffers in each session.
Bug#18522 provides some tools for that.

I couldn’t figure out how to count all_buffers, but I saw (length (buffer-list)), is that sufficient?
--
Aaron

reply via email to

[Prev in Thread] Current Thread [Next in Thread]