|
From: | Dmitry Gutov |
Subject: | Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) |
Date: | Wed, 1 Apr 2020 18:16:04 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |