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: 19 May 2003 10:24:47 +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> <84r86vz8z0.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=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1053334249 19953 80.91.224.249 (19 May 2003 08:50:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 19 May 2003 08:50:49 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 19 10:50:48 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 19HgLl-0005AK-00 for ; Mon, 19 May 2003 10:50:29 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19HgVU-0002ez-00 for ; Mon, 19 May 2003 11:00:32 +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 19Hg6b-0003j7-03 for emacs-devel@quimby.gnus.org; Mon, 19 May 2003 04:34:49 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19Hg5M-00035F-00 for emacs-devel@gnu.org; Mon, 19 May 2003 04:33:32 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19Hg4r-0002Um-00 for emacs-devel@gnu.org; Mon, 19 May 2003 04:33:03 -0400 Original-Received: from mailout07.sul.t-online.com ([194.25.134.83]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19Hfwx-0006Ju-00 for emacs-devel@gnu.org; Mon, 19 May 2003 04:24:52 -0400 Original-Received: from fwd01.sul.t-online.de by mailout07.sul.t-online.com with smtp id 19Hfwx-0003XX-07; Mon, 19 May 2003 10:24:51 +0200 Original-Received: from localhost.localdomain (520018396234-0001@[62.226.11.172]) by fwd01.sul.t-online.com with esmtp id 19Hfww-1kPwXYC; Mon, 19 May 2003 10:24:50 +0200 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h4J8OmZF024023 for ; Mon, 19 May 2003 10:24:49 +0200 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h4J8OmYp024019; Mon, 19 May 2003 10:24:48 +0200 Original-To: emacs-devel@gnu.org In-Reply-To: <84r86vz8z0.fsf@lucy.is.informatik.uni-duisburg.de> Original-Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Sender: 520018396234-0001@t-dialin.net 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:13997 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13997 kai.grossjohann@gmx.net (Kai Gro=DFjohann) writes: > David.Kastrup@t-online.de (David Kastrup) writes: >=20 > > 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. >=20 > I'm not familiar with the internals of Unix (-like) systems, but > maybe it is possible to "look" in such a way that the scheduler has > a chance to do its thing. For example, say that using select(2) > causes the scheduler to run, then we might "look" using select(2). The scheduler _has_ already made its decision, and the decision is to have Emacs run rather than the output generating process. There are various reasons: Emacs has been waiting on that pipe for a longer time, so it is judged an "interactive program" and not a calculating one. It gets an interactivity bonus and gets scheduled immediately when available. This interactivity bonus gets lower while busy processing continues. That is the reason that after a while, a few larger packets make it through. > Hm. But this might make Emacs quite a bit slower. So maybe it is a > good idea to only look twice if little data has been received. If a > lot of data has been read, then we can just process that > immediately. The only way to yield is to actually and voluntarily call a delay. This should only be done when there is reason to suspect it might be worth a try, namely when we find ourselves repeatedly working on small packets in fast succession. Emacs should just refuse to call a process filter too fast twice in a row unless it has stuffed the buffer sufficiently, and it should have a very fast path when it decides not to run the process filter yet. Perhaps a better scheme would be to use _blocking_ reads with the full buffer length and a timeout instead when something is available. When the blocking read fails, get just what is there. --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum