Re: w32-pipe-read-delay (was: vc-dir operation is very slow on large git repositories in Emacs 26.1)

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Fri, 22 Jun 2018 16:43:40 -0400
> 
> BTW, it seems that w32-pipe-read-delay aims to solve a similar issue as
> process-adaptive-read-buffering.

Similar, but different.  It is different in 2 important aspects:

  . w32-pipe-read-delay affects reading only from pipes, whereas
    process-adaptive-read-buffering affects any kind of subprocess;
  . w32-pipe-read-delay is about the sub-process writing to the pipe,
    whereas process-adaptive-read-buffering is about Emacs reading the
    data, and is generally related to how low-level I/O stuff works on
    the system where Emacs runs.

> Does process-adaptive-read-buffering currently apply to w32 subprocesses?

Yes, of course.  But I have never seen it being used or useful on
Windows.

> If so, could it be that w32-pipe-read-delay was made obsolete when
> process-adaptive-read-buffering was added?  If not, why not
> (i.e. what's the fundamental difference between the two)?

I think we should set w32-pipe-read-delay to zero by default
regardless.  As the comment in w32.c, where it is used, explains, it
was added to cater to invoking DOS programs on Windows 9X, which is by
now an extremely rare situation, to say the least.  I just tried the
"dir" command, which it also mentions, with and without the delay, in
a large directory which produces 650KB of output, and saw now effect
at all.

It may still be necessary to set the value non-zero for when the
sub-process treats the pipe as a console, which might be true for some
Cygwin/MSYS ports.  So I'd wait with obsoleting this variable until we
collect enough (negative) experience after changing the value.

(I'm surprised that this variable had such a profound effect with
Git's ls-files, but maybe that has something to do with the MSYS
components in Git on Windows.)