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

[storm@cua.dk (Kim F. Storm)]

David Kastrup <dak@gnu.org> 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 <storm@cua.dk> http://www.cua.dk