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

[Dmitry Gutov]

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%

You can also compare CC Mode's init with JS Mode's.

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".

And there will be more of that during redisplay itself.

> 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.