Re: c-beginning-of-defun in the past and presence

[Alan Mackenzie <acm@muc.de>]

Hi, Martin.

On Sun, Sep 21, 2014 at 11:36:34AM +0200, martin rudalics wrote:
> Dear Alan and friends

> Running with emacs -Q

> (with-current-buffer (find-file-noselect "~/src/xdisp.c")
>    (elp-instrument-function 'c-beginning-of-defun)
>    (goto-char (point-max))
>    (condition-case nil
>        (beginning-of-defun 1000)
>      (error nil))
>    (elp-results))

> gets me here as elapsed time

> Emacs 24.3:   1.672
> Emacs 24.4:   4.516
> Emacs trunk: 27.375


> Running with emacs -Q

> (with-current-buffer (find-file-noselect "~/src/xdisp.c")
>    (elp-instrument-function 'c-beginning-of-defun)
>    (goto-char (point-max))
>    (condition-case nil
>        (while (beginning-of-defun) nil)
>      (error nil))
>    (elp-results))

> gets me here

>               Call Count  Elapsed Time  Average Time

> Emacs 24.3:  353         23.842999999  0.0675439093
> Emacs 24.4:  353         43.000000000  0.1218130311
> Emacs trunk: 353        136.48399999   0.3866402266


> Please try to make things behave reasonably again.

, for some value of "reasonably".  ;-)

I've repeated your timings for the first case (i.e. (beginning-of-defun
1000)) and get pretty much the same results you do.

What is taking the time in the trunk is (presumably) backwards
`scan-lists's, which you can see if you elp-instrument `scan-lists' too.
It is taking longer since Emacs-23 because
`open-paren-in-column-0-is-defun-start' is being bound to nil in
`c-parse-state' to avoid buggy processing.  But I think you know this
anyway.

Stefan committed revision 117351 on 2014-07-04 to the Emacs-24 branch,
which should have helped.  This should have been merged into the trunk by
revision 117499, committed by Glenn on 2014-07-08, and looking at the
source code, it appears it did.  I don't know, at this stage, why the
trunk is so much slower that the Emacs-24 branch.  I'll need to have a
look at this.

In the second case ((while (beginning-of-defun) nil)), it cannot but be
much slower than the first case, since the expensive analysis to move
from the top level '{' to BOD is repeated for every defun, rather than
just being done once, when c-beginning-of-defun is given its repeat
count.  I expect the reason for the slow down between Emacs-24 and trunk
will turn out to be the same as for the first case.

> Thanks, martin

-- 
Alan Mackenzie (Nuremberg, Germany).