bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 25 Jan 2014 10:23:18 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: Alan Mackenzie <acm@muc.de>
> 
>  >> With current trunk and emacs -Q evaluating the following form takes more
>  >> than two minutes here with builds on Windows and GNU/Linux:
>  >
>  >> (progn
>  >>   (setq scroll-conservatively 101)
>  >>   (find-file (concat source-directory "src/xdisp.c"))
>  >>   (end-of-buffer)
>  >>   (sit-for 3)
>  >>   (beginning-of-buffer))
>  >
>  >> It used to take about 10 seconds before revision 116070.
>  >
>  > It's taking me about 7 seconds, on an Emacs version whose latest applied
>  > revision is 116070.
>  >
>  > Quick update to current (latest revision 116146), and rebuild .......
>  >
>  > It's still taking me about 7 seconds.
> 
> Updated to revision 116153, bootstrapped (at least one hour on my
> machine), still taking more than two minutes here.

I see this too, both on Windows and on GNU/Linux.  Here's the profile:

  - redisplay_internal (C function)                                2560  95%
   - jit-lock-function                                             2560  95%
    - jit-lock-fontify-now                                         2560  95%
     - funcall                                                     2560  95%
      - #<compiled 0x4093379>                                      2560  95%
       - run-hook-with-args                                        2560  95%
	- font-lock-fontify-region                                 2560  95%
	 - c-font-lock-fontify-region                              2560  95%
	  - font-lock-default-fontify-region                       2559  95%
	   - font-lock-fontify-keywords-region                     2547  94%
	    - c-font-lock-complex-decl-prepare                     2543  94%
	     - c-parse-state                                       2543  94%
	      - c-parse-state-1                                    2543  94%
	       - c-append-lower-brace-pair-to-state-cache          2542  94%
		  byte-code                                        2542  94%
	       - c-append-to-state-cache                              1   0%
		  byte-code                                           1   0%
	    + #<compiled 0x407e625>                                   3   0%
	    + c-font-lock-enum-tail                                   1   0%
	   + font-lock-fontify-syntactically-region                  12   0%
	  + mapc                                                      1   0%
  + command-execute                                                 116   4%
  + ...                                                               6   0%

This takes about 40 seconds on a fast (Core i7) machine.

>  > As far as I can see, you haven't
>  > installed your temporary patch to syntax.c.
> 
> I'm afraid I have to do that now.
> 
>  > So, I haven't been able to
>  > reproduce the problem yet.
>  >
>  > Is there something more subtle I'm missing?
> 
> Is there something more subtle I'm missing?

Probably.  I actually don't understand how come scroll-conservatively
affects non-scrolling commands.  Can you elaborate on that?

You also mentioned back_comment doing something unreasonable.  Can you
expand on that, too?  This part specifically I don't understand:

> What happens is that apparently back_comment 530 times scans the buffer
> from the beginning of the buffer to the first comment before the current
> position where the list of current positions goes like this:

Since the problem happens as result of beginning-of-buffer, why would
back_comment need to "scan the buffer from the beginning of the buffer
to the first comment before the current position"?  And what is the
current position in this case?

Btw, if I disable font-lock ("M-x global-font-lock-mode RET") before
repeating the recipe, the move to bob is instantaneous, and turning on
font-lock after that doesn't seem to have any adverse effects on
responsiveness.