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: Sun, 04 Mar 2007 09:16:37 +0100 Message-ID: <85wt1xwhi2.fsf@lola.goethe.zz> References: <85tzxazb8r.fsf@lola.goethe.zz> <85irdi1mar.fsf@lola.goethe.zz> <854pp21goy.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 1172996225 6921 80.91.229.12 (4 Mar 2007 08:17:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Mar 2007 08:17:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 04 09:16:59 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 1HNltq-0002tX-UD for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2007 09:16:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNltq-00028m-C6 for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2007 03:16:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNltc-000286-AT for emacs-devel@gnu.org; Sun, 04 Mar 2007 03:16:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNlta-00027u-SA for emacs-devel@gnu.org; Sun, 04 Mar 2007 03:16:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNlta-00027r-L8 for emacs-devel@gnu.org; Sun, 04 Mar 2007 03:16:42 -0500 Original-Received: from mail-in-05.arcor-online.net ([151.189.21.45]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HNltY-0003lQ-UX; Sun, 04 Mar 2007 03:16:41 -0500 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 905A712F2BA; Sun, 4 Mar 2007 09:16:39 +0100 (CET) Original-Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 502BF2C6E34; Sun, 4 Mar 2007 09:16:39 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-052-195.pools.arcor-ip.net [84.61.52.195]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id 1D93328144B; Sun, 4 Mar 2007 09:16:39 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 1F9711C460D3; Sun, 4 Mar 2007 09:16:37 +0100 (CET) In-Reply-To: (Eli Zaretskii's message of "Sun\, 04 Mar 2007 01\:18\:40 +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:67286 Archived-At: Eli Zaretskii writes: >> Cc: rms@gnu.org, emacs-devel@gnu.org >> From: David Kastrup >> 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