From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Fix for slow process output processing (please test). Date: 05 Jan 2004 16:57:14 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87y8so7kjy.fsf@offby1.atm01.sea.blarg.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073320400 14037 80.91.224.253 (5 Jan 2004 16:33:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2004 16:33:20 +0000 (UTC) Cc: Eric Hanchrow , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jan 05 17:33:17 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdXfJ-0001aA-00 for ; Mon, 05 Jan 2004 17:33:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdXfJ-00038C-00 for ; Mon, 05 Jan 2004 17:33:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AdYOz-0004V5-1U for emacs-devel@quimby.gnus.org; Mon, 05 Jan 2004 12:20:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AdYFv-0001EK-RC for emacs-devel@gnu.org; Mon, 05 Jan 2004 12:11:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdYC4-00079G-Qy for emacs-devel@gnu.org; Mon, 05 Jan 2004 12:07:40 -0500 Original-Received: from [217.80.160.111] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AdY4X-00049q-4y for emacs-devel@gnu.org; Mon, 05 Jan 2004 11:59:21 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i05FvI88008684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2004 16:57:19 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i05FvE3S008680; Mon, 5 Jan 2004 16:57:14 +0100 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19014 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19014 storm@cua.dk (Kim F. Storm) writes: > Eric Hanchrow writes: > > > > I've noticed that shell-mode on very recent (i.e., since after New > > Year's) versions of CVS Emacs on Windows is quite slow, and the > > CPU usage is high, for a second or two after I hit RET > > (comint-send-input). I haven't yet investigated, but if this > > sounds like it might be related to your patch (which I think, but > > cannot right now confirm, is present on the Emacs in question), > > let me know if I can give you any more information. > > Does the problem go away if you do > > M-: (setq process-adaptive-read-buffering nil) RET > > before starting shell-mode ? > > I suppose that process-adaptive-read-buffering isn't really needed > on Windows, Since Windows is slow, anyway? > so we could just turn it off in lisp/term/w32-win.el. I suppose the problem could be that the Windows equivalent of "select" that Emacs uses does a busy wait without yielding the CPU. Perhaps this depends on the size of the time slice. So perhaps it would be nice for experiments to be able to set process-adaptive-read-buffering to something more complicated, like a property list setting some parameters, at least for the purpose of debugging. It might help getting relevant feedback from those using Windows. Maybe. On another note, I just recalled that Linux has recently gained something they called an "anticipative I/O scheduler" which means that write requests will not cause the process to be scheduled away immediately, but rather it gets a chance to produce more output (I don't think that this related to the pipes here, though, but mostly for disk writes). I don't know whether or not one should adapt the buzz phrase "adaptive buffering" to rather use "anticipative" as the latter is already "established" in a way. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum