Re: emacs rendering comparisson between emacs23 and emacs26.3

[Alan Mackenzie]

Hello, Dmitry.

On Tue, Apr 07, 2020 at 22:45:25 +0300, Dmitry Gutov wrote:
> Hi Alan,

> On 07.04.2020 20:42, Alan Mackenzie wrote:

> >> Scenarios that are made slower if the file is large are probably caused
> >> by the same architectural decisions that make (find-file "src/xdisp.c")
> >> slow-ish. All those could likely be improved if CC Mode migrated to
> >> using syntax-propertize-function, with its on-demand approach to parsing.

> > Please would you stop saying this.  It's not true, and it gets very
> > wearing.  The crude syntax-propertize-function mechanism would have to
> > be considerably enhanced before it could support CC Mode's features.

> 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.  But this would merely transfer the start up time to the
time taken in early scrolls forward.

> 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?  Anyway, the case you cite has to be handled
well, too.

> It's not a given, but I'd really like to see you try collaborating
> with Stefan. At least for a prototype, to have a better idea of the
> associated performance tradeoffs. He posted a preliminary patch in the
> past, FWIW.

> "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.  Considering that s-t properties have an overwhelmingly local
effect, this is very wasteful of processor time.

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.

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.

Splatting all the properties after the point of change would be
unnecessary and wasteful.

> > And even then, it would be unlikely to be faster than the current CC
> > Mode.

> 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?  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.  Once you do that,
you're effectively doing what CC Mode currently does, so where's the
speed advantage coming from?

-- 
Alan Mackenzie (Nuremberg, Germany).