Re: Default of jit-lock-stealth-time

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: rms@gnu.org,  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 03 Mar 2007 14:36:28 +0100
>> 
>> Apart from "pathological" buffers, paging through a file will deliver
>> font locking fast enough to follow the user action
>
> Where ``fast enough'' means what, precisely?

The limiting factor is the speed with which the user types scrolling
commands.

>> In contrast, left alone to jit-lock-stealth-time=16, Emacs will
>> eventually turn to eating 100% of CPU time (not 1-3%)
>
> How can this happen?  JIT-lock is supposed to fontify at most
> jit-lock-chunk-size characters (500 by default), and then refrain
> from fontification for at least jit-lock-stealth-nice seconds (0.5
> by default).  How can Emacs take 100% of CPU with these defaults?

It does.  If 0.5 seconds is small compared to the time it takes for
the fontification, CPU load will be close to 100%.  Granted, I get
more like 80% on an extended average, but it certainly is enough to
drain the batteries, keep the fan running and render the system
(inside and outside of Emacs) sluggish.

> Maybe there's a bug?

Sigh.  The problem is that _any_ bad font lock pattern in _any_ buffer
could be responsible for the action, and inside of timers, quit is
inhibited.  If there is a bug, stealth-lock makes its effects appear
regardless of what buffer one is editing, while at the same time very
effectively shielding the bug from being debuggable or traceable to a
cause.

> How much time do you need to wait until Emacs starts using 100% of
> CPU on your machine?  I didn't see that, but maybe I didn't wait
> long enough.

Basically, it starts some time after the 16 seconds.

> Also, did you try looking at the percentage of CPU taken by each
> application, when the CPU consumption hits 100%, and if you did, was
> Emacs indeed consuming 100% or thereabouts at that time?

Yes, Emacs was consuming between 70% and 100% at that time.
Repeatably.  This annoyed me for _months_ without being able to trace
it to a cause (and yes, I tried my hand with debug-on-quit and similar
things: stealth fontification "nicely" works around all that).  Only
after a bug report and Richard's suggestion to check out stealth
fontification was I able to get rid of this nonsense.

After months.  And several other Emacs developers have reported to
have used this setting for similar reasons.

>> That does not mean that the problematic files will page through
>> without noticeable delay when I go through them by hand: they tend
>> to react sluggishly to editing.
>
> These delays and sluggishness were what I meant when I talked about
> annoyances.  I don't like them.

Well, guess what: I don't like them when I am editing _unrelated_
buffer or not editing anything at _all_.  Stealth fontification
acerbates the problem by spreading it around your whole desktop so
that it becomes almost impossible to pinpoint it.  But it _does_ _not_
fix the problematic cases.  It just makes it impossible to attribute
them to their cause.

>> I would consider stealth fontification completely useless as long
>> as the computer can keep up with the user, which appears to be the
>> case for your usage.  In that case, investing the power when it is
>> actually needed seems by far the sanest choice.
>
> David, your opinion was heard, loud and clear, several times
> already.  There's no need to reiterate it.  Doing so just wastes
> bandwidth.

I was commenting on your findings.  Do you mean to say that discussion
of your findings is to be prohibited if that could point to the same
conclusion?

> For my part, I can say that investing a small fraction of CPU power
> when none is used is by far wiser than annoying the user with
> redisplay delays, if those are noticeable.

As I said: they are only noticeable when patterns are at work that
make stealth fontification behave _untolerably bad_, without being
debuggable.

The CPU power is not just invested when "none is used", it drains the
power of the system, it suggests that Emacs is the _only_ application
worthy to use CPU power at any time, anyway, and so it is fine for it
to grab it without being asked.  And even if we ignore all that and
make believe that the fairy world in which laptop batteries and any
application except Emacs itself don't count is reality, you still
gloss over the fact that stealth fontification does not even work
transparently within Emacs itself: Emacs reacts sluggishly and the
cursor blink gets erratical (or disappears altogether) when this
happens, and stealth fontification makes it _impossible_ to debug the
cause.

Sure, "maybe there is a bug".  But such bugs can be in the font lock
patterns of any mode, and there is no point in making them
nondebuggable and forcing their effects upon the users, just because
they are "only bugs".

Apart from which I am still of the opinion that an idle Emacs should
in its default setting _not_ consume any CPU power when no events
occur.

An application that turns into a power and CPU hog when it goes
unsupervised is _not_ going to win any trust contests.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum