Re: A possible way for CC Mode to resolve its sluggishness

[Alan Mackenzie]

Hello, Eli.

On Fri, Apr 26, 2019 at 22:53:09 +0300, Eli Zaretskii wrote:
> > Date: Fri, 26 Apr 2019 19:30:56 +0000
> > From: Alan Mackenzie <address@hidden>

> > (i) A CC Mode buffer will be partitioned into @dfn{syntactic cells}.
> > These will be things like a section of code, a comment, a string, a raw
> > string, a CPP construct ....  Possibly even comment delimiters would
> > have their own cells.

> > (ii) Syntactic cells will be implemented by a text property, c-syntax,
> > whose value will indicate the type of the cell, and possibly an
> > identifier for it.  Neighbouring cells will always have distinct
> > c-syntax values.

> Can a syntactic cell have other syntactic cells embedded in it?

No.  Mainly because ....

> Because if it can, you cannot use text properties for that, since text
> properties cannot overlap.

Yes.

> > Thoughts?

> Why do you think this proposal will make CC Mode faster?  Wouldn't
> computing and updating the cells in itself be expensive?

The main speed up will come from only running CC Mode's change functions
occasionally, rather than at every buffer change.

For most changes, there will be no need explicitly to update the cells;
the text property stickiness, and so on, will do that implicitly.  When
there is a need, the cell boundaries will be calculated by existing
algorithms, but these will get run much less frequently.

For example c-fl-decl-start laboriously finds the start of the current
declaration, needed as a context for accurate font-locking.  The
syntactic cells will cache this value, rather than it having to be
continually calculated.  This function is one of the main brakes to CC
Mode's performance.

Also, there are currently a lot of calls to c-literal-limits and
friends, which use an explicit cache together with parse-partial-sexp.
Being able to use text property search instead should be a speedup.

-- 
Alan Mackenzie (Nuremberg, Germany).