From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David.Kastrup@t-online.de (David Kastrup) Newsgroups: gmane.emacs.devel Subject: Re: Any idea about what makes Emacs slow reading on pipes? Date: 18 May 2003 21:46:04 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <5x1xyye3y4.fsf@kfs2.cua.dk> <84smrcskwu.fsf@lucy.is.informatik.uni-duisburg.de> Reply-To: dak@gnu.org NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1053287203 31025 80.91.224.249 (18 May 2003 19:46:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 18 May 2003 19:46:43 +0000 (UTC) Cc: =?iso-8859-1?q?Kai_Gro=DFjohann?= Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 18 21:46:42 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19HU7G-00084E-00 for ; Sun, 18 May 2003 21:46:42 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19HUGi-0003Rg-00 for ; Sun, 18 May 2003 21:56:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19HU8O-0001wg-06 for emacs-devel@quimby.gnus.org; Sun, 18 May 2003 15:47:52 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19HU87-0001sh-00 for emacs-devel@gnu.org; Sun, 18 May 2003 15:47:35 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19HU85-0001rI-00 for emacs-devel@gnu.org; Sun, 18 May 2003 15:47:34 -0400 Original-Received: from mailout04.sul.t-online.com ([194.25.134.18]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19HU70-0001OD-00; Sun, 18 May 2003 15:46:26 -0400 Original-Received: from fwd05.sul.t-online.de by mailout04.sul.t-online.com with smtp id 19HU6z-0000Dj-02; Sun, 18 May 2003 21:46:25 +0200 Original-Received: from localhost.localdomain (520018396234-0001@[62.226.12.133]) by fwd05.sul.t-online.com with esmtp id 19HU6h-0gSPBoC; Sun, 18 May 2003 21:46:07 +0200 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h4IJk5ZF018761; Sun, 18 May 2003 21:46:05 +0200 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h4IJk4W7018757; Sun, 18 May 2003 21:46:04 +0200 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Sender: 520018396234-0001@t-dialin.net Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13978 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13978 Richard Stallman writes: > We might change it so that, after stashing the stuff in a > buffer, Emacs looks again if more data is available from the > same process. More data will not be available from the same process, since the process has not had any chance to get CPU time again for generating more data. We are talking about a uniprocessor machine here. The only way in which more data could become available is if Emacs _voluntarily_ yielded the CPU instead of processing what is there. So the question is how to yield the CPU, and for how long, and when to stop. The best possibility would be to resume when either a number of characters is available (a "read" of a certain size can be satisfied), or a timeout has occured. Unfortunately, I don't see how to achieve this without actually reading the pipe out all of the time. So we do need a temporary buffer which we serve _fast_. If it is full, we process it, if not, we may wait. If waiting does not yield new characters, fire up the filter. How long to wait, depending on the past history and the fill level of our buffer? Good question. > If so, also read it and stash it in the buffer, too. > > That is worth trying--it might not be too hard to write. But I > think the problem is in Linux, so the real solution is to change > Linux. I am following this way by discussing this on the Linux kernel list and am pretty certain that a future version of Linux might be able to deal with this gracefully. But there are other operating systems of which I believe a majority to be afflicted with this uniprocessor-specific problem, and older Linux systems will remain with us for a long time. It would be good if we could equip Emacs with a few heuristics that would not cause noticeable degradations on operating systems that would know how to deal with this scheduling anomaly, but improved matters on the _many_ systems that don't. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum