emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs)
Date: Wed, 01 Apr 2020 07:14:09 +0300
User-agent: K-9 Mail for Android

On April 1, 2020 6:49:45 AM GMT+03:00, Dmitry Gutov <address@hidden> wrote:
> On 01.04.2020 05:28, Eli Zaretskii wrote:
> >> Cc: address@hidden, address@hidden, address@hidden,
> >>   address@hidden
> >> From: Dmitry Gutov <address@hidden>
> >> Date: Tue, 31 Mar 2020 22:50:43 +0300
> >>
> >>>> (benchmark 1 '(progn (find-file "src/xdisp.c") (goto-char
> (point-max))))
> >>>>
> >>>> => Elapsed time: 1.940401s (0.376140s in 6 GCs)
> >>> This doesn't measure the redisplay (which happens after the above
> >>> command returns).
> >>
> >> Which means that the current state of affairs is even slower.
> > 
> > No, it means that whatever delay we will have with parsing the
> entire
> > buffer is _in_addition_ to whatever you measured.
> 
> Probably not. IIUC, most of this 1.2 measured delay is CC Mode doing
> the 
> preliminary parsing.

There's no need to guess.  Just profile this use case, and you will clearly see 
what takes most of this time.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]