[Top][All Lists]

[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: Fri, 11 Mar 2016 18:27:06 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, 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.

Thanks for taking the trouble to try this.  I get the following timings:

            without comment-cache           with comment-cache
foo                 15.64s                         7.89s
bar                 96.53s                        89.93s

So my results are the opposite from yours.  In particular for `foo', the
comment cache gave a dramatic speedup.

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

Sorry.  It seems this is a "popular" observation.  I'm going to have to
spend some time working out what can be taken out of CC Mode, and at
what cost in correctness.  I can't promise much progress quickly, but I
promise to put work into it soon.

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

> Thanks, martin

P.S. I've just run `bar' with elp enabled (all `c-..' functions plus
`parse-partial-sexp' and `scan-lists' being instrumented), and I get the

c-beginning-of-defun                           365         97.659041618  
c-beginning-of-decl-1                          1071        95.573583641  
c-syntactic-skip-backward                      2239        91.440043437  
c-in-knr-argdecl                               1071        90.988073058  
parse-partial-sexp                             392328      86.160691713  

c-beginning-of-statement-1                     1071        4.3989913499  
c-where-wrt-brace-construct                    365         4.0776264500  
c-in-function-trailer-p                        365         2.4348031740  
scan-sexps                                     12402       2.4236885029  

, so it seems fairly obvious now where the saving must come from.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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