From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stephen Gildea Newsgroups: gmane.emacs.devel Subject: Re: jit-lock-stealth-load Date: Sun, 24 Mar 2002 21:10:09 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1017022371 21808 127.0.0.1 (25 Mar 2002 02:12:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 25 Mar 2002 02:12:51 +0000 (UTC) Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16pJyd-0005fd-00 for ; Mon, 25 Mar 2002 03:12:51 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16pK6R-0006go-00 for ; Mon, 25 Mar 2002 03:20:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16pJyB-00056Y-00; Sun, 24 Mar 2002 21:12:23 -0500 Original-Received: from sj1-3-5-7.securesites.net ([192.220.127.8]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16pJw6-00051r-00 for ; Sun, 24 Mar 2002 21:10:14 -0500 Original-Received: (qmail 21223 invoked by uid 25345); 25 Mar 2002 02:10:13 -0000 Original-Received: from unknown (HELO sgildea.best.vwh.net) ([192.220.99.1]) (envelope-sender ) by 192.220.99.1 (qmail-ldap-1.03) with SMTP for ; 25 Mar 2002 02:10:13 -0000 Original-To: emacs-devel@gnu.org In-Reply-To: Message from Richard Stallman of "Sun, 24 Mar 2002 08:53:09 MST." <200203241553.g2OFr9l02719@aztec.santafe.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 20.4 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2177 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2177 > I wonder if there is some way we can make jit-lock gradually > reduce its activities as the load moves above 100, turning off > when it gets to around 150 or 200. This appeals to me, because the load reported to jit-lock is of course a moving average, and one wants jit-lock to respond to instantaneous load. But I would want it to gradually reduce activity much earlier, turning off completely at 100. The magic number is still 100%. How about something like this: jit-lock notes the current time, and does a chunk of a buffer. Then it notes the time again and adjusts its chunk size to try to keep its compute time constant, say 0.1 second. This keeps Emacs responsive on all speeds of CPU. Then it checks the load. If we are at or above the limit, sleep for 30 seconds and check the load again. If we are below the limit, sleep for d*(a - n)/(m - a) with a min of 0 secs and a max of 10 secs. where m is jit-lock-stealth-load (default *still* 100) n is the point at which we start backing off (normally m-100) a is actual system load average d is the time it took to do the last chunk This makes Emacs contribute just enough load to drive the system load towards the limit, backing off as we get close. The value of n is m-100 because Emacs can contribute at most a load of 100%. If the actual load is less than m-100, then Emacs cannot raise it to m even by running continuously; above m-100, Emacs might need to back off to avoid overshooting m. But this would complicate the code, and I'm plenty happy with the current, simple algorithm and jit-lock-stealth-load set to 100. < Stephen _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel