Re: Debouncing slow mode line constructs (was: Emacs design and architecture. How about copy-on-write?)

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1. Every time Emacs processes :eval construct it (a) measures the time
>>    taken; (b) caches return value.
>
> This needs to somehow identify each :eval and record its execution
> time.

Just sxhash, for example.

>> 2. If the total render time exceeds configurable threshold, processing
>>    the most time-consuming :eval constructs will be suspended until
>>    "debounce" time since the last full processing.
>> 
>>    By "suspended", I mean that cached :eval value is reused instead of
>>    invoking :eval again. Possibly, not reused verbatim, but by replacing
>>    the cached value with some kind of placeholder that has the same
>>    total height/width as the cached value.
>
> This needs also to cache the last value of each :eval.

Yes.

> It also assumes that these elements are quasi-static, for long enough
> time to decide which one(s) are slow and reuse their cached values.

You are right. Such assumption may or may not hold. Though nothing
prevents us from deciding based on running average of several previous
:eval processing times instead of just one previous time.

> But mode-line-format is just a variable, and a Lisp program can
> legitimately change it at a high frequency, which will defeat any
> useful caching (because the :eval elements change and no longer match
> their cached entries).

Sure. Though I am not aiming to solve such scenarios. IMHO, they are not
very common.

> ... Moreover, a Lisp program can decide to
> deliberately defeat this caching by relatively simple measures.

I see no reason to prevent that if it is deliberate. The point is that
Lisp program will declare that "yes, I know that mode line may be slow"
by doing such thing. Which should be totally fine as long as it is the
decision made by the Lisp program author.

> ... Last, but not least, all this additional processing will make
> mode-line display slower even if all the :eval forms are completely
> benign.

Maybe. But we can try and see if it is actually going to be the case.

> Also, Emacs has a tradition of leaving Lisp programs enough rope to
> hang themselves, as long as they don't cause crashes and other
> catastrophic outcomes.  This proposal will prevent a Lisp program in
> :eval from doing its thing simply because we don't like its timing
> (which, btw, depends on the CPU power, so a threshold that is an
> absolute number of seconds is not necessarily the best idea).  In some
> quarters, this could be seen as breaking the contract.

IMHO, long-line-threshold, for example, is also breaking the contract
you are referring to. So, if we leave legitimate ways for a program to
bypass this optimization when necessary, it should not be a problem.

> The example with an external Git command is very relevant: using a
> cached value could present to the user completely misleading
> indications.
>
> So I think this is a lot of trouble for little gain, and could be also
> against our long-standing policies.

Well. Strictly speaking, current Git branch may not be up-to-date even
without my proposal. Simply because Emacs gives no guarantees about how
frequently the mode line is refreshed. redisplay optimizations may
decide to not refresh the mode-line when typing.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>