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: 05 Jan 2004 00:00:31 +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 1073253918 17607 80.91.224.253 (4 Jan 2004 22:05:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Jan 2004 22:05:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Jan 04 23:05:13 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdGMz-0002cG-00 for ; Sun, 04 Jan 2004 23:05:13 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdGMz-0005oB-00 for ; Sun, 04 Jan 2004 23:05:13 +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 1AdHJi-0003EA-HI for emacs-devel@quimby.gnus.org; Sun, 04 Jan 2004 18:05:54 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AdHJM-0003C0-4E for emacs-devel@gnu.org; Sun, 04 Jan 2004 18:05:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdHIo-0002IY-R1 for emacs-devel@gnu.org; Sun, 04 Jan 2004 18:05:30 -0500 Original-Received: from [193.162.153.10] (helo=pqueueb.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AdHIH-0001aK-Ul; Sun, 04 Jan 2004 18:04:26 -0500 Original-Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by pqueueb.post.tele.dk (Postfix) with ESMTP id 471023DE291; Sun, 4 Jan 2004 23:02:58 +0100 (CET) Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepc.post.tele.dk (Postfix) with SMTP id BD9EB262A4E; Sun, 4 Jan 2004 23:00:27 +0100 (CET) Original-To: David Kastrup In-Reply-To: Original-Lines: 54 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:18993 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18993 David Kastrup writes: > While I have been abysmally absent in testing this patch before it > finally got applied, I would like to mention that I now benchmarked > the behavior with and without process-adaptive-read-buffering set for > a typical preview-latex document. With the patch, the real time for > the initial LaTeX run (which is somewhat comint-like) was about half > with adaptive read buffering set. And it must be mentioned that I had > already trimmed output to the necessary minimum before because I had > noticed a heavy speed impact for I/O. I suppose we might improve it further by increasing the read buffer size from 1024 bytes to 4096 bytes. I think you could easily try that in process.c. Just change int readmax = 1024; to int readmax = 4096; > > The subsequent GhostScript usage as a daemon (where lines of command > and very brief responses are passed back and forth between Emacs and > GhostScript) was not affected in its operation time. > > One thing that might be worth mentioning in the variable > process-adaptive-read-buffering is that it is conceivable that it > would offer no or slightly negative impact on multiprocessor machines > where the data generating process can make progress independent of the > CPU time Emacs spends on consuming the data. > > It would be nice if somebody that has a multiprocessor box would test > this. If the process can produce output at a sufficient rate, the adaptive read buffering shouldn't be activated at all, so I would suppose that the effect will be minimal > > Thanks a lot: I guess this change will be quite welcome for all users > that use Emacs as shell/terminal/process environment in one way or > another. We still have to see if there are some unwanted effects -- if so, we can fix them by let-binding process-adaptive-read-buffering to nil around start-process calls. There might also be systems where the patch has an overall negative effect; on such systems we should disable it all-together. Time will tell. -- Kim F. Storm http://www.cua.dk