From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Default of jit-lock-stealth-time Date: Sun, 04 Mar 2007 01:18:40 +0200 Message-ID: References: <85tzxazb8r.fsf@lola.goethe.zz> <85irdi1mar.fsf@lola.goethe.zz> <854pp21goy.fsf@lola.goethe.zz> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1172963939 8629 80.91.229.12 (3 Mar 2007 23:18:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2007 23:18:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 04 00:18:52 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 1HNdV3-0005JM-I7 for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2007 00:18:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNdV3-0005SC-1d for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 18:18:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNdUr-0005S5-HC for emacs-devel@gnu.org; Sat, 03 Mar 2007 18:18:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNdUp-0005Re-1b for emacs-devel@gnu.org; Sat, 03 Mar 2007 18:18:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNdUo-0005Rb-Sh for emacs-devel@gnu.org; Sat, 03 Mar 2007 18:18:34 -0500 Original-Received: from cemetery.inter.net.il ([213.8.233.29]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HNdUk-000071-EQ; Sat, 03 Mar 2007 18:18:30 -0500 Original-Received: from nitzan.inter.net.il (nitzan.inter.net.il [213.8.233.22]) by cemetery.inter.net.il (Postfix) with ESMTP id 638881337D0; Sun, 4 Mar 2007 01:18:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([81.5.36.219]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id GEY04632 (AUTH halo1); Sun, 4 Mar 2007 01:18:27 +0200 (IST) In-reply-to: <854pp21goy.fsf@lola.goethe.zz> (message from David Kastrup on Sat, 03 Mar 2007 16:37:33 +0100) X-detected-kernel: FreeBSD 6.x (1) 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:67276 Archived-At: > 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? > >> 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? > > 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. And please cool down, we are discussing technical issues that aren't supposed to get anyone worked out. > > 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. Then perhaps fixing those bad patterns is a better way of dealing with the problem. Can you tell what files exhibit this bad behavior? I'd like to see what happens with them on my machines. > 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. That is what the default values try to accomplish.