From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Fix for slow process output processing (please test). Date: 16 Dec 2003 14:24:17 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071578051 4865 80.91.224.253 (16 Dec 2003 12:34:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 Dec 2003 12:34:11 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Dec 16 13:34:06 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 1AWEOs-0002P3-00 for ; Tue, 16 Dec 2003 13:34:06 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AWEOs-0000Wq-00 for ; Tue, 16 Dec 2003 13:34:06 +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 1AWFHX-00016L-5h for emacs-devel@quimby.gnus.org; Tue, 16 Dec 2003 08:30:35 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AWFH7-00010E-Mw for emacs-devel@gnu.org; Tue, 16 Dec 2003 08:30:09 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AWFGU-0000hv-95 for emacs-devel@gnu.org; Tue, 16 Dec 2003 08:30:02 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.24) id 1AWFDW-0008Fn-MZ for emacs-devel@gnu.org; Tue, 16 Dec 2003 08:26:26 -0500 Original-Received: (qmail 16605 invoked from network); 16 Dec 2003 12:24:58 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 16 Dec 2003 12:24:58 -0000 Original-To: David.Kastrup@t-online.de (David Kastrup) In-Reply-To: Original-Lines: 78 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:18714 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18714 David.Kastrup@t-online.de (David Kastrup) writes: > storm@cua.dk (Kim F. Storm) writes: > > > So if you have a process which manages to write a lot of data in one > > write, emacs should happily read that data with no throttling. > > And if we have a process that writes in small chunks but with very > good CPU utilization (something like dd if=/dev/zero obs=1), then we > will alternate between reading 8192 (or whatever the pipe size is) and > 1 byte. Of course vastly preferable to alternating between reading 1 > byte and 1 byte. The following small change to the previous patch makes the patched process.c run even faster: Replace the line delay += READ_OUTPUT_DELAY_INCREMENT; by delay += READ_OUTPUT_DELAY_INCREMENT * 2; If I run your own "M-x make-test" command with the patched version of process.c on GNU/Linux, I get the following measurements: 102400+0 records in 102400+0 records out finished Time: 0 1 blocks with size 1 1 blocks with size 137 19 blocks with size 1023 61 blocks with size 1024 Time: 1 1 blocks with size 950 4 blocks with size 1023 15 blocks with size 1024 Compare this to the results from the unpatched process.c: 102400+0 records in 102400+0 records out finished Time: 0 311 blocks with size 1 1 blocks with size 1023 3 blocks with size 1024 Time: 1 185 blocks with size 1 Time: 2 231 blocks with size 1 Time: 3 191 blocks with size 1 2 blocks with size 1023 6 blocks with size 1024 Time: 4 113 blocks with size 1 9 blocks with size 1023 27 blocks with size 1024 Time: 5 108 blocks with size 1 8 blocks with size 1023 24 blocks with size 1024 Time: 6 62 blocks with size 1 1 blocks with size 912 4 blocks with size 1023 14 blocks with size 1024 Pretty good improvement IMHO. Of course, if you have examples of things that behave badly with the patched version (i.e. that ran better without the patch), I'd like to know. -- Kim F. Storm http://www.cua.dk