Re: Default of jit-lock-stealth-time

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> Cc: address@hidden,  address@hidden
>> From: David Kastrup <address@hidden>
>> Date: Sat, 03 Mar 2007 16:37:33 +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.
>
> Does it keep up with the keyboard's autorepeat, for example?

I find that under X11 on my machine, processes tend not to be
decoupled to such a high degree that the autorepeat keeps producing
key presses when they are no longer consumed, so there are no
accumulative bad side effects that immediately accompany the point of
"can't keep up".  For me, it tends to keep up.  Note that I changed
the default just about at the time where I started my rant, but then,
Emacs never really got finished with his high-power stealth
fontification jobs, anyway (which is the reason why they are extremely
annoying), and so could not save me much time.

>> >> 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.
>
> It sounds strange that fontification of 500 characters should take
> time much longer than 0.5 seconds.  What happens if you increase the
> value of jit-lock-stealth-nice, does the load go down
> proportionally?

Since the load numbers are not absolutely stable, this is an
experimentation in futility.

>> > 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?
>
> I didn't mean anything except what I said.

Fine, then you were wrong.  I did offer my opinion on your findings
previously, so it could not have been heard before.

> And please cool down, we are discussing technical issues that aren't
> supposed to get anyone worked out.

Well, they _are_ getting my computer worked out, to say the least.

>> As I said: they are only noticeable when patterns are at work that
>> make stealth fontification behave _untolerably bad_, without being
>> debuggable.
>
> Then perhaps fixing those bad patterns is a better way of dealing
> with the problem.

What about "without being debuggable" is hard to understand?  Setting
jit-lock-stealth-verbose to t makes it likely that several files are
affected and in several modes.  One is texbook.tex (but by far not the
only).  But it does not behave similarly bad when viewed directly, and
there is likely some interaction with AUCTeX modes or highlighting
involved, as well.

The problem is that it is _not_ _debuggable_ and affects operations in
_all_ buffers in a non-reproducible way due to stealth fontification.

We really don't want to have a setting that spreads problems with one
buffer/major mode/font lock pattern across _all_ of Emacs' operation.

It makes it close to impossible to ever pinpoint the problem and get
rid of it.

> Can you tell what files exhibit this bad behavior?  I'd like to see
> what happens with them on my machines.

As I said: it depends on several circumstances (like using desktop.el,
so files get loaded without getting displayed, and using several modes
and settings in several combinations).  And it is not reproducible.

>> 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.
>
> We have customizations to take care of significant drain of power.
> We were discussing the defaults.  By default, I think Emacs should
> use up a small fraction of CPU resources when it fontifies
> stealthily.

I disagree.  By default, an idle Emacs session should be idle.  That
is what people expect from an interactive application, and certainly
from an editor.  Without a _very_ good reason, no deviation from that
policy makes sense.  One has to be aware that Emacs is a _large_
application.  If it is sitting idle, the normal behavior under memory
pressure is that it gets mostly paged out in order not to disturb
other processes, and that is sensible behavior.  Stealth
fontification, however, will cause almost _everything_ to get paged in
again since it touches every buffer and every major mode and has to
garbage collect in the process as well.

This is _not_ what an idle interactive program should do, in
particularly not one as large as Emacs.

So even if stealth fontification worked always as intended and no
problematic font lock patterns existed on the world, it would _still_
be a bad idea to enable it without explicit request from the user.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum