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 14:29:48 +0100 Message-ID: <85abytkugj.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 1173015021 19525 80.91.229.12 (4 Mar 2007 13:30:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Mar 2007 13:30:21 +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 Sun Mar 04 14:30:14 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 1HNqn0-0004T5-0B for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2007 14:30:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNqmz-0005Iz-C2 for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2007 08:30:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNqmj-0005Er-Oe for emacs-devel@gnu.org; Sun, 04 Mar 2007 08:29:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNqmi-0005DZ-UY for emacs-devel@gnu.org; Sun, 04 Mar 2007 08:29:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNqmi-0005D4-KS for emacs-devel@gnu.org; Sun, 04 Mar 2007 08:29:56 -0500 Original-Received: from mail-in-13.arcor-online.net ([151.189.21.53]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HNqme-0006mg-5Z; Sun, 04 Mar 2007 08:29:52 -0500 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id B4EFA1E50F1; Sun, 4 Mar 2007 14:29:50 +0100 (CET) Original-Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id A789A345D60; Sun, 4 Mar 2007 14:29:50 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-052-195.pools.arcor-ip.net [84.61.52.195]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 5E4741B3267; Sun, 4 Mar 2007 14:29:50 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 8E2D21C460D3; Sun, 4 Mar 2007 14:29:48 +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:67291 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? > >> 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? Actually, it is more around 75% of CPU time according to "top". Enough to cause a power drain, keep Emacs mapped to memory, and obviously in long enough bursts to keep the computer in general and/or Emacs from being responsive. > Maybe there's a bug? 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. 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? Since I just got hit again (I deleted my customization of jit-lock-stealth-time after checking in the change, but did not actually recompile here), I tried changing jit-lock-stealth-nice. Changing it from the default of 0.5 to a value of 3 will cause the CPU load that top reports Emacs to be taking (when it goes wild) to drop from about 75% (for 0.5) to about 40% (for 3). So a totally wild interpolation would come to the conclusion that the "bad" fontification attempts take about 75%*0.5sec/25% = 1.5sec or 40%*3sec/60%=2sec each, which is similar enough for such a rough estimate. Maybe stealth lock should keep track of the actual time it spends on fontification and calculate its next jit-lock-stealth-nice value based on that. Or should disable stealth lock in buffers that seem not to behave well. As I said, the most common culprit at the moment for me seems to be texbook.tex.gz. I can send you a copy if you want to, but as I said, the problem also seems to depend on some third-party packages. After a few seconds of thrashing, I get the following results from instrumenting font-latex: Function Name Call Count Elapsed Time Average Time ========================================= ========== ============ ============ font-latex-match-command-in-braces 1780 3.2092149999 0.0018029297 font-latex-find-matching-close 970 3.0349990000 0.0031288649 font-latex-match-type-declaration 10 3.012727 0.3012727 font-latex-match-simple-command 62693 2.2595180000 3.604...e-05 font-latex-script 14685 1.3847209999 9.429...e-05 font-latex-match-command-with-arguments 4800 1.2166909999 0.0002534772 font-latex-match-script 14695 1.1428459999 7.777...e-05 font-latex-match-function 4210 0.8861020000 0.0002104755 font-latex-commented-outp 27908 0.7627639999 2.733...e-05 font-latex-unfontify-region 10 0.4944489999 0.0494449 Now 62693 is a large number, and the whole file apparently contains just 37633 occurences of LaTeX commands. The stealth fontification for which I have now profiled just a few seconds, pretty much goes on indefinitely. So it would appear that there is something like quadratic behavior in some circumstances triggered in connection with stealth fontification. So yes, there is likely a bug (or whatever one may call something that takes up too much time) in this particularly severe case, but it is not triggered outside of stealth fontification, and stealth fontification makes the problem be pretty much impossible to debug properly, and triggers it when editing _any_ buffer. I can send you the file in question, but you'll probably need font-latex and possible other AUCTeX components for reproducing the problem. But it is likely to be a black hole: there are other modes with possible font locking problems, and it is just not a good idea to spread their effects across a whole Emacs session. That way, they will much less likely be fixed some day. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum