GNU bug report logs - #23928
25.0.95; Performance regression observable with smartparens

Previous Next

Full log

Message #22 received at 23928 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 23928 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#23928: 25.0.95;
 Performance regression observable with smartparens
Date: Sun, 10 Jul 2016 17:29:27 +0300

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sun, 10 Jul 2016 02:55:31 +0000
> Cc: 23928 <at> debbugs.gnu.org
> 
> I’ve added profiles of both here:  https://gist.github.com/aaronjensen/a1c2b56eac192b0d9cac76b493822070
> 
> In this profile, they’re showing pretty much the exact same performance, so that doesn’t tell us much. I believe the performance degradation is something that happens over time, and these are fresh runs of emacs. I’ll have to try and get from 25 next time it slows down on me.

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?

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

>     And please don't use elp.el to produce profiles, use profiler.el,
>     because the latter can profile primitives as well.
> 
> I don’t even know how to use elp.el, was there some indication that I was?

Sorry, my bad.  It looked like elp.el output to me.

Previous Next

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