all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Fix for slow process output processing (please test).
Date: 03 Jan 2004 16:12:26 +0100	[thread overview]
Message-ID: <x5y8spukv9.fsf@lola.goethe.zz> (raw)
In-Reply-To: <m37k0wdhfi.fsf@kfs-l.imdomain.dk>

storm@cua.dk (Kim F. Storm) writes:

> 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.
> 
> 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:

> 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.

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.

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.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2004-01-03 15:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-16  1:21 Fix for slow process output processing (please test) Kim F. Storm
2003-12-16  2:14 ` David Kastrup
2003-12-16  3:34 ` David Kastrup
2003-12-16 10:23   ` Kim F. Storm
2003-12-16 11:51     ` David Kastrup
2003-12-16 13:24       ` Kim F. Storm
2004-01-03 15:12         ` David Kastrup [this message]
2004-01-04 23:00           ` Kim F. Storm
2004-01-03 22:07 ` Eric Hanchrow
2004-01-04 22:42   ` Kim F. Storm
2004-01-05 15:57     ` David Kastrup
2004-01-05 19:09       ` Eli Zaretskii
2004-01-05 19:39         ` David Kastrup
2004-01-05 19:52         ` Jason Rumney
2004-01-05 23:28           ` Kim F. Storm
2004-01-05 23:16             ` Jason Rumney
2004-01-05 23:44               ` David Kastrup
2004-01-06  0:23                 ` Jason Rumney
2004-01-07  0:40               ` Kim F. Storm
2004-01-05 23:35       ` Kim F. Storm
2004-01-05 22:50         ` David Kastrup
2004-01-06  0:09           ` Kim F. Storm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x5y8spukv9.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.