Fix for slow process output processing (please test).

Fix for slow process output processing (please test).

[Kim F. Storm]

David Kastrup and others have reported very slow processing of process
output, particularly with the Linux kernel's scheduler giving emacs
too much attention while starving the processing producing the output.

Below is a patch which introduces a small delay on reading output from
such processes, without using global delays in processing other events
(this is done by temporarily removing the process' file descriptor from
the call to select and use a short timeout on the select instead.

I have not yet tested this extensively, but would like some feedback
on whether it actually does have the intended positive effect on the
processing of process output.  Could people who have experienced
these problems pls. try the patch and give me feedback.

The patch is against CVS emacs at the time of "server shutdown".

++kfs


*** process.h.~1.24.~	2003-09-01 17:45:56.000000000 +0200
--- process.h	2003-12-16 00:39:22.000000000 +0100
***************
*** 101,106 ****
--- 101,115 ----
         generated, and can be changed by the function
         `set-process-fileter-multibyte'. */
      Lisp_Object filter_multibyte;
+     /* Hysteresis to try to read process output in larger blocks.
+        On some systems, e.g. the Linux kernel, emacs is seen as 
+        an interactive app also when reading process output, meaning
+        that process output can be read in as little as 1 byte at a
+        time.  Value is micro-seconds to delay reading output from
+        this process.  Range is 0 .. 50000.  */
+     Lisp_Object read_output_delay;
+     /* Skip reading this process on next read.  */
+     Lisp_Object read_output_skip;
  };
  
  /* Every field in the preceding structure except for the first two

*** process.c.~1.417.~	2003-11-16 22:25:47.000000000 +0100
--- process.c	2003-12-16 02:00:47.000000000 +0100
***************
*** 260,265 ****
--- 260,282 ----
  #undef DATAGRAM_SOCKETS
  #endif
  
+ #ifdef EMACS_HAS_USECS
+ 
+ #define READ_OUTPUT_DELAY_INCREMENT 10000
+ #define READ_OUTPUT_DELAY_MAX       (READ_OUTPUT_DELAY_INCREMENT * 5)
+ #define READ_OUTPUT_DELAY_MAX_MAX   (READ_OUTPUT_DELAY_INCREMENT * 7)
+ 
+ /* Number of processes which might be delayed.  */
+ 
+ static int process_output_delay_count;
+ 
+ /* Non-zero if any process has non-nil process_output_skip.  */
+ 
+ static int process_output_skip;
+ #else
+ #define process_output_delay_count 0
+ #endif
+ 
  
  #include "sysselect.h"
  
***************
*** 573,578 ****
--- 590,600 ----
    p->status = Qrun;
    p->mark = Fmake_marker ();
  
+ #ifdef READ_OUTPUT_DELAY_INCREMENT
+   XSETFASTINT (p->read_output_delay, 0);
+   p->read_output_skip = Qnil;
+ #endif
+ 
    /* If name is already in use, modify it until it is unused.  */
  
    name1 = name;
***************
*** 3588,3593 ****
--- 3610,3625 ----
    inchannel = XINT (p->infd);
    outchannel = XINT (p->outfd);
  
+ #ifdef READ_OUTPUT_DELAY_INCREMENT
+   if (XINT (p->read_output_delay) > 0)
+     {
+       if (--process_output_delay_count < 0)
+ 	process_output_delay_count = 0;
+       XSETINT (p->read_output_delay, 0);
+       p->read_output_skip = Qnil;
+     }
+ #endif
+       
    if (inchannel >= 0)
      {
        /* Beware SIGCHLD hereabouts. */
***************
*** 3973,3979 ****
    register int channel, nfds;
    static SELECT_TYPE Available;
    static SELECT_TYPE Connecting;
!   int check_connect, no_avail;
    int xerrno;
    Lisp_Object proc;
    EMACS_TIME timeout, end_time;
--- 4005,4011 ----
    register int channel, nfds;
    static SELECT_TYPE Available;
    static SELECT_TYPE Connecting;
!   int check_connect, check_delay, no_avail;
    int xerrno;
    Lisp_Object proc;
    EMACS_TIME timeout, end_time;
***************
*** 4202,4208 ****
        if (!NILP (wait_for_cell))
  	{
  	  Available = non_process_wait_mask;
! 	  check_connect = 0;
  	}
        else
  	{
--- 4234,4240 ----
        if (!NILP (wait_for_cell))
  	{
  	  Available = non_process_wait_mask;
! 	  check_connect = check_delay = 0;
  	}
        else
  	{
***************
*** 4211,4216 ****
--- 4243,4249 ----
  	  else
  	    Available = input_wait_mask;
  	  check_connect = (num_pending_connects > 0);
+ 	  check_delay = process_output_delay_count;
  	}
  
        /* If frame size has changed or the window is newly mapped,
***************
*** 4236,4241 ****
--- 4269,4302 ----
  	{
  	  if (check_connect)
  	    Connecting = connect_wait_mask;
+ 
+ #ifdef READ_OUTPUT_DELAY_INCREMENT
+ 	  if (process_output_skip && check_delay > 0)
+ 	    {
+ 	      int usecs = EMACS_USECS (timeout);
+ 	      if (EMACS_SECS (timeout) > 0 || usecs > READ_OUTPUT_DELAY_MAX)
+ 		usecs = READ_OUTPUT_DELAY_MAX;
+ 	      for (channel = 0; check_delay > 0 && channel <= max_process_desc; channel++)
+ 		{
+ 		  proc = chan_process[channel];
+ 		  if (NILP (proc))
+ 		    continue;
+ 		  if (XPROCESS (proc)->read_output_delay > 0)
+ 		    {
+ 		      check_delay--;
+ 		      if (NILP (XPROCESS (proc)->read_output_skip))
+ 			continue;
+ 		      FD_CLR (channel, &Available);
+ 		      XPROCESS (proc)->read_output_skip = Qnil;
+ 		      if (XINT (XPROCESS (proc)->read_output_delay) < usecs)
+ 			usecs = XINT (XPROCESS (proc)->read_output_delay);
+ 		    }
+ 		}
+ 	      EMACS_SET_SECS_USECS (timeout, 0, usecs);
+ 	      process_output_skip = 0;
+ 	    }
+ #endif
+ 
  	  nfds = select (max (max_process_desc, max_keyboard_desc) + 1,
  			 &Available,
  			 (check_connect ? &Connecting : (SELECT_TYPE *)0),
***************
*** 4689,4695 ****
    else
  #endif
    if (proc_buffered_char[channel] < 0)
!     nbytes = emacs_read (channel, chars + carryover, readmax - carryover);
    else
      {
        chars[carryover] = proc_buffered_char[channel];
--- 4750,4785 ----
    else
  #endif
    if (proc_buffered_char[channel] < 0)
!     {
!       nbytes = emacs_read (channel, chars + carryover, readmax - carryover);
! #ifdef READ_OUTPUT_DELAY_INCREMENT
!       if (!NETCONN1_P (p))
! 	{
! 	  int delay = XINT (p->read_output_delay);
! 	  if (nbytes < readmax - carryover)
! 	    {
! 	      if (delay < READ_OUTPUT_DELAY_MAX_MAX)
! 		{
! 		  if (delay == 0)
! 		    process_output_delay_count++;
! 		  delay += READ_OUTPUT_DELAY_INCREMENT;
! 		}
! 	    }
! 	  else if (delay > 0)
! 	    {
! 	      delay -= READ_OUTPUT_DELAY_INCREMENT;
! 	      if (delay == 0)
! 		process_output_delay_count--;
! 	    }
! 	  XSETINT (p->read_output_delay, delay);
! 	  if (delay)
! 	    {
! 	      p->read_output_skip = Qt;
! 	      process_output_skip = 1;
! 	    }
! 	}
! #endif
!     }
    else
      {
        chars[carryover] = proc_buffered_char[channel];
***************
*** 6503,6508 ****
--- 6593,6603 ----
    FD_ZERO (&non_process_wait_mask);
    max_process_desc = 0;
  
+ #ifdef READ_OUTPUT_DELAY_INCREMENT
+   process_output_delay_count = 0;
+   process_output_skip = 0;
+ #endif
+ 
    FD_SET (0, &input_wait_mask);
  
    Vprocess_alist = Qnil;

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

[David Kastrup]

no-spam@cua.dk (Kim F. Storm) writes:

> David Kastrup and others have reported very slow processing of
> process output, particularly with the Linux kernel's scheduler
> giving emacs too much attention while starving the processing
> producing the output.
> 
> Below is a patch which introduces a small delay on reading output
> from such processes, without using global delays in processing other
> events (this is done by temporarily removing the process' file
> descriptor from the call to select and use a short timeout on the
> select instead.
> 
> I have not yet tested this extensively, but would like some feedback
> on whether it actually does have the intended positive effect on the
> processing of process output.  Could people who have experienced
> these problems pls. try the patch and give me feedback.

One thing that I mentioned might be a good idea is to cancel any
prospective delay on the next read when something is sent to the
process.  In that manner there will be no delay when some protocol is
talked instead of just output collected.

> The patch is against CVS emacs at the time of "server shutdown".

I have experimented around with several (quite more naive) approaches
myself, never reaching a point that would have been worth discussing,
let alone committing, so I don't have a reasonably clean process.c.
Could you send me a complete copy of yours in private mail?

Thanks.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[David Kastrup]

no-spam@cua.dk (Kim F. Storm) writes:

> David Kastrup and others have reported very slow processing of process
> output, particularly with the Linux kernel's scheduler giving emacs
> too much attention while starving the processing producing the output.
> 
> Below is a patch which introduces a small delay on reading output from
> such processes, without using global delays in processing other events
> (this is done by temporarily removing the process' file descriptor from
> the call to select and use a short timeout on the select instead.

I have glanced over that patch.  There is one problem I see with it:
if indeed the generating process is able to produce lots of data with
a single write call, Emacs will be throttling its input without a
purpose.

This situation is quite more probable when we have a multiprocessor
machine or when the input is generated by some network process (so
again, on a different CPU).

The best behavior would be
a) don't bother reading from the pipe for a while if it is not yet
   full.
b) process it immediately once it is completely full.

The select call does not offer any possibility to say "wake up
immediately if there is such an amount of data".  And we need the
select call to poll other input, so we can't just use blocking I/O
with a timeout set (which would probably be the best solution if we
had only to worry about a single source of input).

`Enterprise level' solutions would probably be:
a) use blocking I/O with a timeout set in a separate thread.  When
the timeout hits or the read completes, whatever has accumulated in
the corresponding input buffer is marked for processing and made
available to the main Emacs.
b) use aio_read to request a full pipe worth of data.  If no signal
announces the availability of the data, some timeout may be used to
cancel the aio_read if there is data available, but not a full pipe
worth of it.

Of course, those solutions are more operating system specific than the
current one.  It may well be that there are few applications that will
turn out worse by throttling Emacs to something like 8kB/20ms or so.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David.Kastrup@t-online.de (David Kastrup) writes:

> > David Kastrup and others have reported very slow processing of process
> > output, particularly with the Linux kernel's scheduler giving emacs
> > too much attention while starving the processing producing the output.
> > 
> > Below is a patch which introduces a small delay on reading output from
> > such processes, without using global delays in processing other events
> > (this is done by temporarily removing the process' file descriptor from
> > the call to select and use a short timeout on the select instead.
> 
> I have glanced over that patch.  There is one problem I see with it:
> if indeed the generating process is able to produce lots of data with
> a single write call, Emacs will be throttling its input without a
> purpose.

With the patch, emacs only throttles if it reads less than 1024 bytes
at a time from the process -- i.e. if the process is unable to produce
data fast enough to fill emacs's read buffer.

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.

Of course, if it has just read some (slower) data with throttling, the
first few 1024 packages will still be trottled (max 100ms total), but
then it would read the rest at full speed.

> 
> This situation is quite more probable when we have a multiprocessor
> machine or when the input is generated by some network process (so
> again, on a different CPU).

If you have a multi-processor system, and your process generates
output at a steady (fast) stream, emacs will not do throttling on that
process.  Only if that process slows down, you will see throttling --
but how would you notice that?

And network traffic is not throttled by this patch!

> 
> The best behavior would be
> a) don't bother reading from the pipe for a while if it is not yet
>    full.
> b) process it immediately once it is completely full.

c) or process it after some timeout if there is any data in the pipe

Yes, there are various ways to accomplish this, but I would rather try
to find a simple solution which works reasonably well in most/all
cases, rather than a more complex (and perhaps o/s specific) solution
that I'm not really sure will work much better in general.

> 
> The select call does not offer any possibility to say "wake up
> immediately if there is such an amount of data".  And we need the
> select call to poll other input, so we can't just use blocking I/O
> with a timeout set (which would probably be the best solution if we
> had only to worry about a single source of input).
> 
> `Enterprise level' solutions would probably be:
> a) use blocking I/O with a timeout set in a separate thread.  When
> the timeout hits or the read completes, whatever has accumulated in
> the corresponding input buffer is marked for processing and made
> available to the main Emacs.
> b) use aio_read to request a full pipe worth of data.  If no signal
> announces the availability of the data, some timeout may be used to
> cancel the aio_read if there is data available, but not a full pipe
> worth of it.
> 
> Of course, those solutions are more operating system specific than the
> current one.  It may well be that there are few applications that will
> turn out worse by throttling Emacs to something like 8kB/20ms or so.
> 

We may go for more advanced solutions, if the current patch does not
solve the problem (maybe with some tuning of the throttling
parameters).

But I would like some feedback on the effects of the current patch
first (also on multi-processor systems if possible); maybe it just
happens to be "good enough" in practice.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[David Kastrup]

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

> David.Kastrup@t-online.de (David Kastrup) writes:
> 
> > > David Kastrup and others have reported very slow processing of process
> > > output, particularly with the Linux kernel's scheduler giving emacs
> > > too much attention while starving the processing producing the output.
> > > 
> > > Below is a patch which introduces a small delay on reading output from
> > > such processes, without using global delays in processing other events
> > > (this is done by temporarily removing the process' file descriptor from
> > > the call to select and use a short timeout on the select instead.
> > 
> > I have glanced over that patch.  There is one problem I see with it:
> > if indeed the generating process is able to produce lots of data with
> > a single write call, Emacs will be throttling its input without a
> > purpose.
> 
> With the patch, emacs only throttles if it reads less than 1024 bytes
> at a time from the process -- i.e. if the process is unable to produce
> data fast enough to fill emacs's read buffer.
> 
> 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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[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

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

[David Kastrup]

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

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

[Eric Hanchrow]

>>>>> "Kim" == Kim F Storm <no-spam@cua.dk> writes:

    Kim> David Kastrup and others have reported very slow processing
    Kim> of process output, particularly with the Linux kernel's
    Kim> scheduler giving emacs too much attention while starving the
    Kim> processing producing the output.

    Kim> Below is a patch

...

I've noticed that shell-mode on very recent (i.e., since after New
Year's) versions of CVS Emacs on Windows is quite slow, and the CPU
usage is high, for a second or two after I hit RET
(comint-send-input).  I haven't yet investigated, but if this sounds
like it might be related to your patch (which I think, but cannot
right now confirm, is present on the Emacs in question), let me know
if I can give you any more information.
 
-- 
Software is largely a service industry operating under the
persistent but unfounded delusion that it is a manufacturing
industry.
        -- Eric Raymond

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

[Kim F. Storm]

Eric Hanchrow <offby1@blarg.net> writes:

> >>>>> "Kim" == Kim F Storm <no-spam@cua.dk> writes:
> 
>     Kim> David Kastrup and others have reported very slow processing
>     Kim> of process output, particularly with the Linux kernel's
>     Kim> scheduler giving emacs too much attention while starving the
>     Kim> processing producing the output.
> 
>     Kim> Below is a patch
> 
> ...
> 
> I've noticed that shell-mode on very recent (i.e., since after New
> Year's) versions of CVS Emacs on Windows is quite slow, and the CPU
> usage is high, for a second or two after I hit RET
> (comint-send-input).  I haven't yet investigated, but if this sounds
> like it might be related to your patch (which I think, but cannot
> right now confirm, is present on the Emacs in question), let me know
> if I can give you any more information.

Does the problem go away if you do

        M-: (setq process-adaptive-read-buffering nil) RET

before starting shell-mode ?

I suppose that process-adaptive-read-buffering isn't really needed on Windows,
so we could just turn it off in lisp/term/w32-win.el.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[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

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

[David Kastrup]

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

> Eric Hanchrow <offby1@blarg.net> writes:
> > 
> > I've noticed that shell-mode on very recent (i.e., since after New
> > Year's) versions of CVS Emacs on Windows is quite slow, and the
> > CPU usage is high, for a second or two after I hit RET
> > (comint-send-input).  I haven't yet investigated, but if this
> > sounds like it might be related to your patch (which I think, but
> > cannot right now confirm, is present on the Emacs in question),
> > let me know if I can give you any more information.
> 
> Does the problem go away if you do
> 
>         M-: (setq process-adaptive-read-buffering nil) RET
> 
> before starting shell-mode ?
> 
> I suppose that process-adaptive-read-buffering isn't really needed
> on Windows,

Since Windows is slow, anyway?

> so we could just turn it off in lisp/term/w32-win.el.

I suppose the problem could be that the Windows equivalent of
"select" that Emacs uses does a busy wait without yielding the CPU.
Perhaps this depends on the size of the time slice.

So perhaps it would be nice for experiments to be able to set
process-adaptive-read-buffering to something more complicated, like a
property list setting some parameters, at least for the purpose of
debugging.  It might help getting relevant feedback from those using
Windows.  Maybe.

On another note, I just recalled that Linux has recently gained
something they called an "anticipative I/O scheduler" which means that
write requests will not cause the process to be scheduled away
immediately, but rather it gets a chance to produce more output (I
don't think that this related to the pipes here, though, but mostly
for disk writes).  I don't know whether or not one should adapt the
buzz phrase "adaptive buffering" to rather use "anticipative" as the
latter is already "established" in a way.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: 05 Jan 2004 16:57:14 +0100
> > 
> > I suppose that process-adaptive-read-buffering isn't really needed
> > on Windows,
> 
> Since Windows is slow, anyway?

I think the reason is that Windows never feeds Emacs with such small
chunks from a pipe.

> I suppose the problem could be that the Windows equivalent of
> "select" that Emacs uses does a busy wait without yielding the CPU.

I think that's not true: it does yield the CPU.  See w32proc.c:sys_select.

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

[David Kastrup]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > From: David Kastrup <dak@gnu.org>
> > Date: 05 Jan 2004 16:57:14 +0100
> > > 
> > > I suppose that process-adaptive-read-buffering isn't really needed
> > > on Windows,
> > 
> > Since Windows is slow, anyway?
> 
> I think the reason is that Windows never feeds Emacs with such small
> chunks from a pipe.
> 
> > I suppose the problem could be that the Windows equivalent of
> > "select" that Emacs uses does a busy wait without yielding the
> > CPU.
> 
> I think that's not true: it does yield the CPU.  See
> w32proc.c:sys_select.

More exactly: my guess is that the equivalent may yield the CPU to
the operating system, but the operating system may be of the opinion
that it will prefer to use up short delay slots by an active wait
rather than letting other processes run.  In short: it is my
suspicion that the yielded CPU time does not arrive at the intended
place.  You could not know this from Emacs sources, however.  We'd
need somebody with Windows insights to get more of a clue.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jason Rumney]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > From: David Kastrup <dak@gnu.org>
> > Date: 05 Jan 2004 16:57:14 +0100
> > > 
> > > I suppose that process-adaptive-read-buffering isn't really needed
> > > on Windows,
> > 
> > Since Windows is slow, anyway?
> 
> I think the reason is that Windows never feeds Emacs with such small
> chunks from a pipe.

Maybe, but my understanding was that big chunks would still be
reasonably fast using the new code, so we should try to find
out. Perhaps there is a bug in our version of select that does not
handle this situation properly, or perhaps the new buffering code needs
further improvements.

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

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
> 
> > storm@cua.dk (Kim F. Storm) writes:
> > 
> > > I suppose that process-adaptive-read-buffering isn't really needed
> > > on Windows,
> > 
> > Since Windows is slow, anyway?
> 
> Because the purpose of my patch was to fix a problem reported to be
> specific for recent Linux kernels.

Not just recent ones.  They may have parameters acerbating the
problem, but it has always been there.  IIRC, the same effect was
reported from FreeBSD; and I think it likely that almost all operating
systems that proud themselves on high throughput and good
interactivity and fast context switches will suffer from the same
phenomenon when running on single processor machines, as long as they
are able to reschedule the moment input arrives in a pipe.  You need
pretty wild scheduler strategies (like "anticipative scheduling") in
order to avoid this effect.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jason Rumney]

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

> With the code below (provided by David some time ago), I see a big
> difference on the Linux 2.4 kernel I'm using (Redhat 9.0).
>
> Maybe someone can try it (just do M-x make-test) with and without
> adaptive buffering enabled on windows.

I have tried running the code, but I'm not sure I understand this well
enough to interpret the results. With adaptive buffering on, we get
more 1024 byte blocks, but we get nothing for Time: 0 (which may be a
symptom of the noticeable delay that was reported?), and we also have
a Time: 9, which I think might mean it is taking longer overall. The
numbers are all in at least the high hundreds for both tests, so maybe
Windows is doing some buffering behind the scenes anyway.


With adaptive buffering on:         With adaptive buffering off:

102400+0 records in                 102400+0 records in
102400+0 records out                102400+0 records out
finished                            finished
Time:  1                            Time:  0
   1 blocks with size  838             1 blocks with size  740
   1 blocks with size  860             2 blocks with size 1024
   1 blocks with size  882          Time:  1
   1 blocks with size  959             1 blocks with size  811
   8 blocks with size 1024             1 blocks with size  823
Time:  2                               1 blocks with size  830
   1 blocks with size  846             1 blocks with size  832
   1 blocks with size  971             1 blocks with size  925
   1 blocks with size  991             1 blocks with size  934
   9 blocks with size 1024             1 blocks with size  949
Time:  3                               1 blocks with size  959
   1 blocks with size  956             1 blocks with size  969
   1 blocks with size  969             1 blocks with size  995
   1 blocks with size  998             1 blocks with size 1024
   1 blocks with size 1017          Time:  2
   8 blocks with size 1024             1 blocks with size  728
Time:  4                               1 blocks with size  812
   1 blocks with size  846             1 blocks with size  815
   1 blocks with size  904             1 blocks with size  915
   1 blocks with size  927             1 blocks with size  925
   7 blocks with size 1024             1 blocks with size  930
Time:  5                               1 blocks with size  934
   1 blocks with size  888             1 blocks with size  939
   1 blocks with size  892             1 blocks with size  941
   1 blocks with size  904             1 blocks with size  961
   1 blocks with size  935             1 blocks with size  964
   8 blocks with size 1024             1 blocks with size  966
Time:  6                               1 blocks with size  984
   1 blocks with size  810             1 blocks with size  992
   1 blocks with size  830             1 blocks with size 1005
   1 blocks with size  875          Time:  3
   1 blocks with size  907             1 blocks with size  825
   8 blocks with size 1024             1 blocks with size  828
Time:  7                               1 blocks with size  873
   1 blocks with size  694             1 blocks with size  886
   1 blocks with size  852             1 blocks with size  929
   1 blocks with size  895             1 blocks with size  930
   1 blocks with size  921             2 blocks with size  933
   9 blocks with size 1024             1 blocks with size  947
Time:  8                               1 blocks with size  982
   1 blocks with size  841             1 blocks with size  988
   1 blocks with size  866             1 blocks with size  990
   1 blocks with size  929             1 blocks with size  993
   1 blocks with size  961             1 blocks with size 1000
   8 blocks with size 1024             1 blocks with size 1009
Time:  9                            Time:  4
   1 blocks with size  502             1 blocks with size  631
   1 blocks with size  575             1 blocks with size  811
   1 blocks with size  589             1 blocks with size  843
   1 blocks with size  608             1 blocks with size  891
   1 blocks with size  773             1 blocks with size  931
   1 blocks with size  886             1 blocks with size  935
   1 blocks with size  920             1 blocks with size  987
   1 blocks with size  992             1 blocks with size  989
   3 blocks with size 1024             1 blocks with size 1002
                                       1 blocks with size 1011
                                       1 blocks with size 1017
                                       3 blocks with size 1024
                                    Time:  5
                                       1 blocks with size  876
                                       1 blocks with size  879
                                       1 blocks with size  898
                                       1 blocks with size  908
                                       1 blocks with size  910
                                       1 blocks with size  912
                                       1 blocks with size  926
                                       1 blocks with size  990
                                       1 blocks with size  991
                                       1 blocks with size  996
                                       1 blocks with size  998
                                       2 blocks with size 1001
                                       1 blocks with size 1018
                                    Time:  6
                                       1 blocks with size  751
                                       1 blocks with size  874
                                       1 blocks with size  894
                                       1 blocks with size  912
                                       1 blocks with size  930
                                       1 blocks with size  944
                                       1 blocks with size  965
                                       1 blocks with size  995
                                       1 blocks with size 1002
                                       1 blocks with size 1007
                                       1 blocks with size 1012
                                    Time:  7
                                       1 blocks with size  849
                                       1 blocks with size  866
                                       1 blocks with size  902
                                       1 blocks with size  909
                                       1 blocks with size  912
                                       1 blocks with size  929
                                       1 blocks with size  940
                                       1 blocks with size  942
                                       1 blocks with size  945
                                       1 blocks with size  947
                                       1 blocks with size  951
                                       1 blocks with size  955
                                       1 blocks with size 1003
                                       1 blocks with size 1005
                                    Time:  8
                                       1 blocks with size  849
                                       1 blocks with size  852
                                       1 blocks with size  905
                                       1 blocks with size  922
                                       1 blocks with size  926
                                       1 blocks with size  927
                                       1 blocks with size  935
                                       1 blocks with size  940
                                       2 blocks with size  942
                                       1 blocks with size  943
                                       1 blocks with size  946
                                       1 blocks with size  951

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

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> "Eli Zaretskii" <eliz@elta.co.il> writes:
> 
> > > From: David Kastrup <dak@gnu.org>
> > > Date: 05 Jan 2004 16:57:14 +0100
> > > > 
> > > > I suppose that process-adaptive-read-buffering isn't really needed
> > > > on Windows,
> > > 
> > > Since Windows is slow, anyway?
> > 
> > I think the reason is that Windows never feeds Emacs with such small
> > chunks from a pipe.
> 
> Maybe, but my understanding was that big chunks would still be
> reasonably fast using the new code, so we should try to find
> out. Perhaps there is a bug in our version of select that does not
> handle this situation properly, or perhaps the new buffering code needs
> further improvements.

With the code below (provided by David some time ago), I see a big
difference on the Linux 2.4 kernel I'm using (Redhat 9.0).

Maybe someone can try it (just do M-x make-test) with and without
adaptive buffering enabled on windows.


(defvar test-pattern nil)
(defvar test-start nil)

(defun test-filter (process string printer)
  (push (cons (floor (- (float-time) test-start))
	      (length string)) test-pattern)
  (princ string printer))

(defun test-predicate (a b)
  (if (equal (car a) (car b))
      (< (cdr a) (cdr b))
    (< (car a) (car b))))

(defun test-sentinel (process string printer finish)
  (princ string printer)
  (delete-process process)
  (setq test-pattern (sort test-pattern #'test-predicate))
  (let (elt lastelt lastcount)
    (while
	(prog1
	    (setq elt (pop test-pattern))
	  (if (equal lastelt elt)
	      (when lastelt (setq lastcount (1+ lastcount)))
	    (when lastelt
	      (princ (format "%4d blocks with size %4d\n"
			     lastcount (cdr lastelt)) printer))
	    (setq lastcount 1)))
      (when (not (eq (car lastelt) (car elt)))
	(princ (format "Time:%3d\n" (car elt)) printer))
      (setq lastelt elt)))
  (if finish (funcall finish)))

(defun make-test (printer &optional finish)
  (interactive (let ((buffer (get-buffer-create "*test*")))
		  (switch-to-buffer buffer)
		  (erase-buffer)
		  (list buffer)))
  (setq test-pattern nil test-start (float-time))
  (let ((process (start-process
		  "test" (and (bufferp printer) printer) "sh"
		  "-c" "od -v /dev/zero|dd bs=1 count=100k")))
    (set-process-filter process `(lambda (process string)
				   (test-filter process string
						',printer)))
    (set-process-sentinel process `(lambda (process string)
				     (test-sentinel process string
						    ',printer ',finish)))
    process))



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I suppose that process-adaptive-read-buffering isn't really needed
> > on Windows,
> 
> Since Windows is slow, anyway?

Because the purpose of my patch was to fix a problem reported to be
specific for recent Linux kernels.

But of coures, it may have a positive effect on other systems as well...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > With the code below (provided by David some time ago), I see a big
> > difference on the Linux 2.4 kernel I'm using (Redhat 9.0).
> >
> > Maybe someone can try it (just do M-x make-test) with and without
> > adaptive buffering enabled on windows.
> 
> I have tried running the code, but I'm not sure I understand this
> well enough to interpret the results. With adaptive buffering on, we
> get more 1024 byte blocks, but we get nothing for Time: 0 (which may
> be a symptom of the noticeable delay that was reported?), and we
> also have a Time: 9, which I think might mean it is taking longer
> overall. The numbers are all in at least the high hundreds for both
> tests, so maybe Windows is doing some buffering behind the scenes
> anyway.

What kind of machine do you have?  Single or double processor?  Is
the processor capable of hyperthreading?

Anyway, it would appear that the effect of adaptive buffering would be
rather negative (as witnessed by the initial large delay).  We should
certainly try to find out what causes this large delay because the
cause might be impacting Emacs in other areas as well.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > David Kastrup <dak@gnu.org> writes:
> > 
> > > storm@cua.dk (Kim F. Storm) writes:
> > > 
> > > > I suppose that process-adaptive-read-buffering isn't really needed
> > > > on Windows,
> > > 
> > > Since Windows is slow, anyway?
> > 
> > Because the purpose of my patch was to fix a problem reported to be
> > specific for recent Linux kernels.
> 
> Not just recent ones.  They may have parameters acerbating the
> problem, but it has always been there.  IIRC, the same effect was
> reported from FreeBSD; and I think it likely that almost all operating
> systems that proud themselves on high throughput and good
> interactivity and fast context switches will suffer from the same
> phenomenon when running on single processor machines, as long as they
> are able to reschedule the moment input arrives in a pipe.  You need
> pretty wild scheduler strategies (like "anticipative scheduling") in
> order to avoid this effect.

I see -- and agree.

BTW, did you try to increase the buffer size?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Jason Rumney]

David Kastrup <dak@gnu.org> writes:

> What kind of machine do you have?  Single or double processor?  Is
> the processor capable of hyperthreading?

Single Processor: x86 Family 6 Model 8 Stepping 10 GenuineIntel ~796 Mhz
whatever that means. Hyperthreading wasn't introduced until at least
the P4 was it?

> Anyway, it would appear that the effect of adaptive buffering would be
> rather negative (as witnessed by the initial large delay).  We should
> certainly try to find out what causes this large delay because the
> cause might be impacting Emacs in other areas as well.

Agreed.

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

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> I have tried running the code, but I'm not sure I understand this well
> enough to interpret the results. With adaptive buffering on, we get
> more 1024 byte blocks, but we get nothing for Time: 0 (which may be a
> symptom of the noticeable delay that was reported?), and we also have
> a Time: 9, which I think might mean it is taking longer overall. The
> numbers are all in at least the high hundreds for both tests, so maybe
> Windows is doing some buffering behind the scenes anyway.

I just made a small adjustment to the adaptive read buffering
algorithm, which I think will make it behave better on Windoze
(without making it behave worse with Linux kernels).

Please test the new version, and see if it behaves better than before.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk