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: MacOS X: Carbon Emacs problem Date: 01 Dec 2003 03:35:17 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <4E2ACA66-23A5-11D8-88C9-000A9573DA0A@rfc.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070246269 26533 80.91.224.253 (1 Dec 2003 02:37:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2003 02:37:49 +0000 (UTC) Cc: =?iso-8859-1?q?Rolf_Marvin_B=F8e_Lindgren?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 01 03:37:46 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQdwY-0000P3-00 for ; Mon, 01 Dec 2003 03:37:46 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQdwX-0006uo-00 for ; Mon, 01 Dec 2003 03:37:45 +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 1AQese-0000uG-Kl for emacs-devel@quimby.gnus.org; Sun, 30 Nov 2003 22:37:48 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AQesJ-0000tz-9L for emacs-devel@gnu.org; Sun, 30 Nov 2003 22:37:27 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AQern-0000HU-HE for emacs-devel@gnu.org; Sun, 30 Nov 2003 22:37:26 -0500 Original-Received: from [217.80.160.65] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AQerm-0000GS-PP for emacs-devel@gnu.org; Sun, 30 Nov 2003 22:36:55 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB12ZOe8030628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2003 03:35:27 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB12ZIWL030624; Mon, 1 Dec 2003 03:35:18 +0100 Original-To: Martin Fredriksson In-Reply-To: <4E2ACA66-23A5-11D8-88C9-000A9573DA0A@rfc.se> Original-Lines: 58 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:18240 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18240 [Toppost rearranged] Martin Fredriksson writes: > > Let me guess. You are working on a single processor system. The > > reason for this may well be something which I already brought up > > here once which will on _many_ single processor operating systems > > result in _very_ inefficient operation: when Emacs is listening on > > a pipe, it will wake up and process a single byte willingly. But > > while Emacs is processing this single byte (and Emacs usually is > > rated an interactive application by the scheduler and thus does > > not get preempted), the application producing the byte does not > > get any CPU time. So when Emacs has finished processing that > > single byte and gives back the CPU to the scheduler, the output > > generating program will again just generate a single byte (or > > sometimes line) before Emacs gets control of the CPU again. But > > it is maximally inefficient to have a pipe only be processed with > > such small units. > > > > Try some of the following remedies: > > > > M-x customize-variable TeX-command-list RET > > > > And then append to the TeXing command you usually use > > > > |dd obs=8k > > > > which should fill the pipe with much larger chunks. Another > > possibility is to do > > > > (defadvice TeX-command-filter (before TeX-pipe-fill) > > (when (< (length string) 80) > > (sleep-for 0.05))) > > > > This will, in case the filter function receives only a short string, > > actively yield the CPU for a moment in which the pipe can fill some > > more. Please report whether this increases throughput on your > > machine. > Thanks for a very informative (and quick!) answer. The 'dd obs=8k' > really improved speed! Great! The filter did not noticably improve > speed; I have not experimented with different sleep times (do you > want me to do that?). Before you do that, it might make more sense to just activate the advice in the first place. I am so stupid. Try (defadvice TeX-command-filter (before TeX-pipe-fill activate) (when (< (length string) 80) (sleep-for 0.05))) [rest snipped to spare the list a repetition of my proposal] It would also be nice if you tried looking at what difference in real time those changes make on your machine, just to press home the point. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum