GNU bug report logs - #43631
28.0.50; CC Mode multiline strings grinds performance to a halt

Previous Next

Package: emacs;

Reported by: Theodor Thornhill <theo <at> thornhill.no>

Date: Sat, 26 Sep 2020 11:18:01 UTC

Severity: normal

Found in version 28.0.50

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Theodor Thornhill <theo <at> thornhill.no>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 43631 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
Date: Mon, 28 Sep 2020 21:41:12 +0200
Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Theo.
>

[...]
>> I see that when I remove 'c-before-change-check-unbalanced-strings from
>> 'c-get-state-before-change-functions' the performance degradation
>> ceases.  I'm not sure what else is affected by that change, so not sure
>> if that can be counted as a fix as far as 'csharp-mode' is concerned.
>
> I would strongly recommend you not to make such a change, at least not
> without a good deal of matching changes elsewhere.  ;-)

Yeah, I put it back in some time ago ;)

>
> It seems the bit in c-b-c-check-unbalanced-strings dealing with
> multiline strings was written on the assumption that buffers containing
> such would be small.
>
> With multiline strings, _any_ change involving quote characters can flip
> the string/non-string characterisation from point all the way to the end
> of the buffer.  In the worst case scenario, this potentially big region
> needs to be analysed and have syntax-table text properties throughout
> the entire region changed.
>
> The current problem is that c-b-c-check-u-strings is doing this analysis
> for every buffer change.  This was easier to code, but has led to
> performance problems on buffers which aren't small.  The solution to
> this will have to involve restricting this analysis to when quote marks
> or the c-multiline-string-start-char get inserted or removed.  That way,
> there should only be an occasional and tolerable delay when one of these
> characters is inserted/removed.
>
> I'll be looking at this in the coming days.
>

Thats very interesting, and thanks!

--
Theo




This bug report was last modified 1 year and 282 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.