Re: Fix for slow process output processing (please test).

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> address@hidden (David Kastrup) writes:
> 
> > address@hidden (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