From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Default of jit-lock-stealth-time Date: Sat, 03 Mar 2007 16:37:33 +0100 Message-ID: <854pp21goy.fsf@lola.goethe.zz> References: <85tzxazb8r.fsf@lola.goethe.zz> <85irdi1mar.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1172936288 29246 80.91.229.12 (3 Mar 2007 15:38:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2007 15:38:08 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 03 16:38:00 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HNWJ4-0000f3-D0 for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 16:37:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNWJ3-00081J-Vw for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 10:37:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNWIo-0007uE-Rt for emacs-devel@gnu.org; Sat, 03 Mar 2007 10:37:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNWIn-0007qg-L2 for emacs-devel@gnu.org; Sat, 03 Mar 2007 10:37:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNWIn-0007qL-Fs for emacs-devel@gnu.org; Sat, 03 Mar 2007 10:37:41 -0500 Original-Received: from mail-in-06.arcor-online.net ([151.189.21.46]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HNWIi-0002ox-O9; Sat, 03 Mar 2007 10:37:37 -0500 Original-Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 293972C8A49; Sat, 3 Mar 2007 16:37:35 +0100 (CET) Original-Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 163252D37C4; Sat, 3 Mar 2007 16:37:35 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-027-182.pools.arcor-ip.net [84.61.27.182]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id E0277236E41; Sat, 3 Mar 2007 16:37:34 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id AA5981C460D3; Sat, 3 Mar 2007 16:37:33 +0100 (CET) In-Reply-To: (Eli Zaretskii's message of "Sat\, 03 Mar 2007 17\:10\:55 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.94 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67259 Archived-At: Eli Zaretskii writes: >> Cc: rms@gnu.org, emacs-devel@gnu.org >> From: David Kastrup >> 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