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 12:03:28 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <5x1xyye3y4.fsf@kfs2.cua.dk> <5xznllw0wp.fsf@kfs2.cua.dk> <84of20skuq.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 1053252199 19166 80.91.224.249 (18 May 2003 10:03:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 18 May 2003 10:03:19 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 18 12:03:17 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 19HL0f-0004yp-00 for ; Sun, 18 May 2003 12:03:17 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19HL9v-0006OV-00 for ; Sun, 18 May 2003 12:12:51 +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 19HL1M-0003SD-04 for emacs-devel@quimby.gnus.org; Sun, 18 May 2003 06:04:00 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19HL0y-0003LY-00 for emacs-devel@gnu.org; Sun, 18 May 2003 06:03:36 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19HL0u-0003Ev-00 for emacs-devel@gnu.org; Sun, 18 May 2003 06:03:34 -0400 Original-Received: from mailout02.sul.t-online.com ([194.25.134.17]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19HL0t-0003CW-00 for emacs-devel@gnu.org; Sun, 18 May 2003 06:03:32 -0400 Original-Received: from fwd04.sul.t-online.de by mailout02.sul.t-online.com with smtp id 19HL0t-0004X2-04; Sun, 18 May 2003 12:03:31 +0200 Original-Received: from localhost.localdomain (520018396234-0001@[62.226.12.133]) by fwd04.sul.t-online.com with esmtp id 19HL0s-0AtuDIC; Sun, 18 May 2003 12:03:30 +0200 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h4IA3TZF012446 for ; Sun, 18 May 2003 12:03:29 +0200 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h4IA3SoH012442; Sun, 18 May 2003 12:03:28 +0200 Original-To: emacs-devel@gnu.org In-Reply-To: <84of20skuq.fsf@lucy.is.informatik.uni-duisburg.de> Original-Lines: 56 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:13967 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13967 kai.grossjohann@gmx.net (Kai Gro=DFjohann) writes: > Another thought that I'm having is that I wonder whether your kernel > includes the scheduler changes that are supposed to favor > interactive applications. It seems that the kernel might think that > Emacs is an interactive application, and so it schedules Emacs > quickly, hoping to improve interactive performance. >=20 > Just a wild stab in the dark. It pretty obviously does. Here is a test: start an xterm. Then run od -v /dev/zero|dd obs=3D1 in it. Then, in some other shell window, type while true;do :; done The original xterm grinds to a halt immediately while the shell is using up its interactivity bonus. Then the xterm resumes work again, at a much _higher_ speed than before. The moment you kill off the busy loop, the xterm drops to a crawl again. I remember this "slow start" xterm effect where an xterm got much faster real time performance on a busy rather than on an idle system and performance got good only when the xterm could not keep up, from a lot of single CPU Unices. One of those quirks one does not think about much. And the faster an operating system can switch contexts, and the more it prouds itself of little latency, the worse the effects get. Yes, I hope to persuade the Linux kernel crowd of a scheduling policy that will fix this situation. But since Emacs runs on a wagonload of different systems, and this situation is all too common, it would not do harm to think of a scheme where Emacs does not spend so much time on every context switch it is handed out generously. That is, I would like a scheme where Emacs throttles the filter routine calls for the benefit of other tasks it is not even responsible for. It could maintain its own buffer that it fills on wakeup without further processing until it is either full or until a certain time since the last processing has elapsed, and only then do the much more expensive operation of running a filter routine instead of yielding again to the operating system. That is, if the operating system is lavish with incurring context switches on a single CPU system, it may be because it can switch contexts quite fast. So we should let Emacs deal with the context switch fast, too. Throttling multibyte conversions and filter routines with the help of a separate buffer should be a way to achieve that without impacting performance on systems with a smarter scheduler. --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum