bug#45898: 27.1; wedged in redisplay again

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Phil Sainty <psainty@orcon.net.nz>,  Emacs-hacker2018@jovi.net,
>   45898@debbugs.gnu.org
> Date: Tue, 14 Jun 2022 14:00:53 +0200
> 
> > Yes.  That idea came up while discussing this with Gerd Möllmann, btw.
> > It's much simpler than measuring time (which would require
> > high-resolution timing, which is much less portable and more tricky to
> > get right, what with modern systems constantly adjusting their time).
> 
> I don't think we need high resolution time here?  We just need to
> (coarsely) have an opinion about whether we've been spending a lot of
> time...

The problem is that redisplay and related code is spread all over the
place, and what makes things low is not necessarily a series of
consecutive calls, let alone predictable ones.  So inserting calls to
timing functions is problematic, and adding times instead of adding
"ticks" would need high-res timing, otherwise you'd risk adding a lot
of zeros.

> > That's why update_redisplay_ticks accepts its first argument, instead
> > of always adding 1: I thought about some potentially expensive
> > operations that could be either more or less expensive than just
> > processing a single character.  E.g., font-lock calls regexp matching,
> > so we should try to come up with some measure of its "expensiveness"
> > based on...something.  This will need some tuning, but all we need is
> > some coarse correlation.
> 
> Yes.  I do wonder, though, whether there's going to be possible to come
> up with useful tuning here -- predicting whether a regexp is "heavy" is
> non trivial, to say the least.

The idea is not to predict it, but to know it after the expensive
operation returned.  Not that doing that is trivial...  Basically, any
operation that is very expensive loops somewhere, so counting the loop
iterations can give some idea of the "cost".