Re: emacs rendering comparisson between emacs23 and emacs26.3

[Dmitry Gutov]

Hi Alan,

On 08.04.2020 05:09, Alan Mackenzie wrote:

> > I will shut up about it now (saying it twice it plenty), but I am pretty
> > confident saying that if you manage to migrate to s-p-f, file opening
> > time will go down.
>
> I'm sure it would.  If file opening time were really a concern, a hybrid
> algorithm would perhaps be the best way: apply the text properties first
> in a lazy fashion, and thereafter treat them with care, as CC Mode
> currently does.

s-p-f would help with the first step, and as for "treating them with 
care", it would be good for us all to see how much of that is really 
needed. Improving syntax-propertize is not out of the question, and it 
might benefit several major modes, not just the CC collection.

> But this would merely transfer the start up time to the
> time taken in early scrolls forward.

Not really. The start up scans the whole buffer, doesn't it? The early 
scrolls forward would still scan only a fraction of it.

> > Performance while typing is likely to improve too, at least when the
> > same buffer is not shown in another window, many thousand lines later.
>
> What makes you think this?

Inserting characters can alter the syntax state of the whole buffer. At 
least that's true for some of them. Full buffer scan sounds inevitable 
in those cases.

> > "Considerable enhancement" can also be a part of that discussion.
>
> The syntax-propertize-function mechanism works by erasing ALL
> syntax-table properties after a change point, then reapplying them
> lazily.

That's not right. It only erases syntax-table properties in a chunk 
before calling syntax-propertize-function on the same range of 
positions. IOW, is overwrites them lazily as well.

> Considering that s-t properties have an overwhelmingly local
> effect, this is very wasteful of processor time.

It would have been. As you can see, it's not a difficult problem to fix, 
even if it were still present.

> Consider, for example, editing within a large C++ raw string, a common
> occurrence.  You yourself reported as a bug sluggish performance here in
> mid 2016.  The cause was erasing too many s-t text properties at a
> buffer change.  I think we were talking about 1 second per typed
> character in the scenario you gave.  There are typically lots of these
> properties in a raw string, in particular on " characters.

I'm pretty sure I have thought of that example because it's an instance 
of a syntax problem that's easy enough to solve within 
syntax-propertize-function framework.

> Consider(2) a C++ template: excusing my C++ syntax knowledge, type in
>
>     template class foo < bar, baz >= bar>
>
> , perhaps typing in the odd newline inside the template (a common
> occurrence), or nesting further templates inside it (also a common
> occurrence).  Note how the parenthesis text properties are added and
> removed as you type.  All these modification are necessary, and they are
> largely _before_ the point of insertion, not after it.

The current implementation of applying these properties can probably be 
transferred into a syntax-propertize-function with only modest changes.

> > Some scenarios can become slower, that's for sure. But the more common
> > ones can get faster. We won't know until we try.
>
> Trying would be a _lot_ of work.  How is one to handle the common
> example scenarios above?

Stefan has offered to help. And I'm sure he could answer the follow-up 
questions much better than I.

> Well, you'd have to enhance the
> syntax-propertize-function with a means of determining a start position
> for erasing s-t props, and also a stop position.

The real-world uses of s-p-f out there already solve syntax problems of 
comparable complexity. And move the start position, among other things.

> Once you do that,
> you're effectively doing what CC Mode currently does, so where's the
> speed advantage coming from?

From doing things more lazily, is how I see it. But I'm not an expert 
on CC Mode architecture.

Among other benefits, moving it to a standard-ish framework like s-p-f 
could (possibly) simplify its code, as well as make it more approachable 
for other developers already familiar with how most other major modes 
are written. So far I wouldn't even know where to start fixing bugs in 
it, and IMHO CC Mode currently has bus factor = 1. It's not great for 
its future. I suspect it's not ideal for you either.

Simply collaborating with one other developer on an overhaul project 
(whether it succeeds or not; perhaps partially) can improve on that.

  Cheers.