Re: Reliable after-change-functions (via: Using incremental parsing in Emacs)

[Dmitry Gutov]

On 01.04.2020 18:59, Eli Zaretskii wrote:

> > What are your measurements, though?
>
> My full profile is below.  This is from Emacs 27.0.90 compiled with
> the -Og optimization and with wide-int (which slows down Emacs by
> about 30%).

Thank you. I also build with '-Og -g3' these days, but probably have a 
faster CPU.

> > Again, what does this print out?
> >
> >     (benchmark 1 '(progn (find-file "src/xdisp.c")))
>
>    Elapsed time: 1.733853s (0.140584s in 6 GCs)

All right. So it takes 1.7s just to open the file, even before full 
syntax highlighting.

> > No 'goto-char'. As we've established, it only affects the time taken by
> > redisplay, and I can't measure that. So I'm not profiling it either,
> > otherwise I'd be comparing apples to oranges.
>
> See the second profile below.

Comparing both, looks like redisplay (when at eob, at least) takes 
approx. the same amount of time?

> > Yes. The numbers can be different, but there is definitely some up-front
> > computation there. One that's not present with e.g. js-mode.
>
> So you are saying that we should do that up-front computation just
> because CC mode currently does it?  That we shouldn't try to eliminate
> such preprocessing?  I don't think so.

AFAIU CC Mode could actually eliminate it, but that would require a 
significant rework of its internals.

I'm just pointing out that apparently you didn't even notice an even 
larger delay (1.7s), and were fine with it until now.

I'm not saying that nobody should try to explore how to decrease the 
delay, and what tradeoffs come with that. But for now, I think, we 
should encourage our kind volunteers to just implement integration the 
way TreeSitter's authors expect it. And try, on our side, to provide the 
best tools for it. Then we can see how well it does or doesn't work, and 
what are the biggest annoyances that the users have with it.