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

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

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 <storm@cua.dk> http://www.cua.dk