emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text


From: Alan Mackenzie
Subject: Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.
Date: Sat, 12 Mar 2016 17:08:39 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello again, Martin.

On Wed, Mar 09, 2016 at 08:58:23PM +0100, martin rudalics wrote:
>  > ... and so far there's been no
>  > feedback from anybody else who's tried it.

> With emacs -Q and non-optimized builds I've been profiling the following
> two primitives

> (defun foo ()
>    (interactive)
>    (while (not (eobp))
>      (c-end-of-defun)))

> (defun bar ()
>    (interactive)
>    (while (not (bobp))
>      (c-beginning-of-defun)))

> to scan the entire buffer of current master's xdisp.c.  The results of
> current master with or without your change are approximately the same
> ‘foo’ taking about 73 seconds, ‘bar’ about 8 minutes, in both cases the
> comment-cache version was slightly slower.

> However, ‘foo’ is about ten times slower than for a version of Emacs
> 24.2 which is about two times slower than for a version of Emacs 23.0.
> ‘bar’ is about 5 times slower than the Emacs 24.2 version which is 3.5
> times slower than the one from Emacs 23.0.

> So, for example, executing ‘bar’ for my Emacs 23.0 took 24.89 seconds
> (0.068 for an average call) versus 464.375 seconds (1.272 average) with
> the comment-cache version.  This means that performance has deteriorated
> by a factor of 18 over the past years.  This also means that I cannot
> use non-optimized builds for my daily work any more.

> Maybe someone could try to test these two functions in a similar fashion
> so we have at least some numbers to base judgements on.  Sometimes it
> seems to me that I'm living in a different world ...

There was a nasty little bug in a low level "get me to the beginning of
a literal" function which caused it to do repeated parse-partial-sexp
from BOB.  Could you try out the patch below, please, which should fix
it, and make `bar' go at the same speed as 'foo'.  I'd be interested in
your general impression as to whether CC Mode seems any faster because
of this fix.

Now, if only we had a nice fast method of determining whether we were in
a literal, and then getting out of it .....  :-)

diff --git a/lisp/progmodes/cc-engine.el b/lisp/progmodes/cc-engine.el
index 66b5369..3ce2c23 100644
--- a/lisp/progmodes/cc-engine.el
+++ b/lisp/progmodes/cc-engine.el
@@ -4277,7 +4277,8 @@ c-ssb-lit-begin
   ;; Use `parse-partial-sexp' from a safe position down to the point to check
   ;; if it's outside comments and strings.
   (save-excursion
-    (let ((pos (point)) safe-pos state)
+    (let ((pos (point)) safe-pos state
+         (c-state-cache (copy-tree c-state-cache)))
       ;; Pick a safe position as close to the point as possible.
       ;;
       ;; FIXME: Consult `syntax-ppss' here if our cache doesn't give a good
@@ -4288,8 +4289,7 @@ c-ssb-lit-begin
        (setq safe-pos-list (cdr safe-pos-list)))
       (unless (setq safe-pos (car-safe safe-pos-list))
        (setq safe-pos (max (or (c-safe-position
-                                (point) (or c-state-cache
-                                            (c-parse-state)))
+                                (point) (c-parse-state))
                                0)
                            (point-min))
              safe-pos-list (list safe-pos)))


> Thanks, martin

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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