Re: emacs communication with subprocess is slow

[Eli Zaretskii <eliz@gnu.org>]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Fri, 03 Oct 2014 12:51:18 -0500
> 
> This may be related to http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18420
> 
> I'm using Emacs pretest 24.3.93, with the patch from 18240, on Windows 7.
> 
> I've run into another problem with Emacs communication with external
> processes; there seems to be a delay on every task switch. This shows up
> both when sending data to the subprocess, and when reading from it.
> 
> I haven't tested this on Debian yet.
> 
> The delay is not present in Emacs 24.3 on Windows 7.
> 
> When sending the contents of an Emacs buffer (source code to be parsed)
> to the subprocess, if the read buffer in the subprocess is
> large enough to hold the entire contents, no delay is apparent. However,
> if the buffer is smaller, so that several reads are needed, then a delay
> appears. 

Sorry, I don't understand: Emacs 24.3 would simply deaqdlock in this
situation, as we have established in bug #18420.  But you say that not
only does it not hang, it is even faster.  What am I missing?

And what exactly does "large enough" mean here?  What sizes are we
talking about?

Also, can you quantify the delays?

> I can use a large buffer in my subprocess for read as a workaround, but
> I have no control over the read buffer in Emacs (perhaps that could be
> added?).

You could try playing with 2 parameters that currently are fixed: the
size of the pipe buffer (set by pipe2 in w32.c, where we use 0 which
AFAIK defaults to 4KB); and the delay used by send_process in
process.c when it gets EAGAIN/EWOULDBLOCK from the 'write' call
(currently 20 milliseconds).

> Should I reopen 18240, or start a new bug?

A new one, of course.  This is an entirely different issue.