Re: [PATCH] Re: cc-mode fontification feels random

[Alan Mackenzie]

Hello, Eli.

On Tue, Aug 31, 2021 at 19:21:40 +0300, Eli Zaretskii wrote:
> > Date: Tue, 31 Aug 2021 16:02:45 +0000
> > Cc: monnier@iro.umontreal.ca, dancol@dancol.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > What happens if you unleash this jit-lock-single-fontification, and
> > > then type at a relatively slow pace: does Emacs still feel responsive
> > > enough?  And how much of CPU does it use in that case?

> > I'm guessing at the moment

> Well, my point, if it wasn't clear, was to suggest that you or someone
> else actually try that and see what happens and how does it feel.
> Emacs is a complex beast, so the results might surprise us all.

Yes, you were clear, sorry I was not as clear in my reply.  I'm
currently working out how to implement it.  It shouldn't be too
difficult or take too long.

> > but I'm reckoning that if jit-lock-single-fontification uses
> > (marginally over) 0.05s at a time, followed by (at least) 0.1s
> > break, normal typing at up to ten characters per second shouldn't be
> > affected.

> Not sure where did the 0.05 sec number come from.

I remember reading somewhere that this is the approximate length of time
which is effectively instantaneous to the human consciousness.  It would
in any case be a configurable option.

> You want to limit the fontification of a chunk to that time, but we
> don't have an efficient method of doing that, because Emacs is not an
> interrupt-driven program.

On my 4 year old HW, approximately 5 CC Mode chunks fit into that time,
on average.  I think the way to do it is to fontify a chunk at a time,
and if the 0.05s hasn't yet been used up, fontify another one, and so
on.  This should work fine on a modern machine, it might cause
sluggishness on an older slower machine, which would be fontifying a
single chunk which might take, say, 0.1s or 0.2s.  This might
necessitate different settings than for a fast machine.

> So if a Lisp program starts some heavy processing, it will only be
> able to stop when it gets to looking at how much time passed, or tests
> some flag set by a signal handler.  There can be no guarantee this can
> never exceed 50 msec.

No.  But doing a chunk at a time, checking the clock after each chunk,
will probably be granular enough.  Again, lets try it and see.

> > As for how much CPU, then I think it would use one third of a single
> > core's CPU time on an otherwise idle Emacs.  That's 0.05s strenuous
> > activity followed by 0.1s break.

> 30% of an execution unit is not negligible.  When I see something like
> that on my system that I presume should be idle, I start looking for
> an offender.  And I'm not sure the 30% estimate is accurate.  Once
> again, let's measure it.

Indeed!

-- 
Alan Mackenzie (Nuremberg, Germany).