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

[Dmitry Gutov]

On 01.04.2020 17:04, Eli Zaretskii wrote:
> > Cc: address@hidden, address@hidden, address@hidden
> > From: Dmitry Gutov <address@hidden>
> > Date: Wed, 1 Apr 2020 16:47:02 +0300
> >
> > On 01.04.2020 07:14, Eli Zaretskii wrote:
> >
> > > There's no need to guess.  Just profile this use case, and you will clearly see 
> > > what takes most of this time.
> >
> >     - c-mode                                      772  75%
> >      - c-common-init                              766  74%
> >       - mapc                                      764  74%
> >        - #<compiled 0x158957d29ef1>                509  49%
> >         + c-neutralize-syntax-in-CPP                276  26%
> >         + c-after-change-mark-abnormal-strings                204  19%
> >         + c-parse-quotes-after-change                 18   1%
> >        - #<compiled 0x158957d29ee5>                255  24%
> >         + c-before-change-check-unbalanced-strings                199  19%
> >         + c-depropertize-CPP                       46   4%
> >         c-font-lock-init                            1   0%
> >         c-basic-common-init                         1   0%
>
> I see a very different picture here: the above takes something like
> 15%.  Most of the time is spent in functions called by jit-lock.

What are your measurements, though? Again, what does this print out?

  (benchmark 1 '(progn (find-file "src/xdisp.c")))

> > If I just (push '("\\.c\\'" . js-mode) auto-mode-alist), the same
> > benchmark takes ~60ms. So yes, CC Mode does a lot during initialization,
> > and that stuff can be described as "preliminary parsing".
>
> Except that I cannot reproduce these results, so I'm not really sure
> what we are looking at.
>
> What I did was start the profiler, then manually call got-char, then
> produce the profiler report.  What did you do to collect the above
> profile?

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.

> > And there will be more of that during redisplay itself.
>
> Which is not what your benchmark measures.

Exactly. Like I said, I can't measure how long redisplay itself takes.

> > > In general, there's no "preliminary processing" by the major mode's 
> > > fontification facilities except what happens as part of jit-lock, i.e. at redisplay time 
> > > or as side effect of functions that simulate display for redisplay purposes.  I'd be very 
> > > surprised to see a major mode which somehow preprocesses the buffer on its own in 
> > > preparation for fontification.  CC Mode certainly doesn't seem to do that.
> >
> > Now you know.
>
> Do I?

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.