bug#30367: 26.0.91; CC-Mode: Major slowdown when isearching big C++ file.

[Bastian Beischer <bastian.beischer@gmail.com>]

Hello Alan,

Alan Mackenzie <acm@muc.de> writes:

> On Thu, Feb 08, 2018 at 17:25:58 +0000, Alan Mackenzie wrote:
>> Hello, Bastian.
>
> [ .... ]
>
>> I think I understand what's happening, now.
>
>> c-looking-at-or-maybe-in-bracelist attempts to go back over the innards
>> of a brace list to the enclosing "{".  At L+122, in new handling for a
>> comma, I rather rashly inserted a `c-go-up-list-backward' to test whether
>> the comma is inside a brace.  This was in a loop, once for each sexp.
>
>> In your sample file there is, at L10,653 a construct at top level with
>> _lots_ of commas.  My loop is trying to go to the non-existent containing
>> brace for each of these commas, so ends up scanning to BOB for each of
>> them.  This entire activity will be being done several times.
>
>> I timed a single `c-go-up-list-backward' from one of these commas at
>> 0.033 seconds.  30 of these take about a second, and my machine is
>> anything but slow.
>
>> So, I just need to work out a way of fixing this, which may take some
>> while (sorry).
>
> Actually, that cond arm with the `c-go-up-list-backward' was merely an
> "optimisation".  :-(  If I simply remove it, the code goes ~30 times
> faster, without triggering any successes in the test suite.
>
> Would you please try out the following patch on real code, and either
> confirm to me that it fixes the bug, or tell me what it breaks.  Thanks!
>
>
>
> diff -r e8b2c6141f97 cc-engine.el
> --- a/cc-engine.el	Fri Feb 02 20:34:15 2018 +0000
> +++ b/cc-engine.el	Thu Feb 08 18:39:40 2018 +0000
> @@ -10547,13 +10547,6 @@
>  		      (looking-at c-return-key))
>  		 (setq braceassignp t)
>  		 nil)
> -		((and c-has-compound-literals
> -		      (eq (char-after) ?,))
> -		 (save-excursion
> -		   (when (and (c-go-up-list-backward nil lim)
> -			      (eq (char-after) ?\())
> -		     (setq braceassignp t)
> -		     nil)))
>  		((eq (char-after) ?=)
>  		 ;; We've seen a =, but must check earlier tokens so
>  		 ;; that it isn't something that should be ignored.
>
>
>
> [ .... ]
>

Yes, this patch fixes the slowdown. But since I don't understand what
the original commit which introduced the slowdown tried to fix I cannot
comment on whether or not its the right thing to do within the context
of that commit.

I will run emacs with the patch included for a while and will let you
know in case I find any problems!

Thanks for tackling this so quickly!

>> > Cheers
>> > Bastian