bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a ha


From: Alan Mackenzie
Subject: bug#43631: 28.0.50; CC Mode multiline strings grinds performance to a halt
Date: Mon, 28 Sep 2020 19:33:25 +0000

Hello, Theo.

On Sun, Sep 27, 2020 at 13:34:32 +0200, Theodor Thornhill wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> [...]


> > But I'm confused why the "fast" profile starts with
> > font-lock-fontify-region, whereas the "slow" profile doesn't have
> > font-lock-fontify-region anywhere...

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

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.

> Just wanted to let you know.

> Theo

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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