GNU bug report logs -
#18626
24.3.94; communication with subprocess is slow
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stephen Leake <stephen_leake <at> stephe-leake.org>
>> Cc: 18626 <at> debbugs.gnu.org
>> Date: Wed, 08 Oct 2014 08:29:59 -0500
>>
>> The cause for this is the Sleep in _sys_read_ahead in w32.c. This is
>> called from reader_thread after the wait for a single char read
>> succeeds. The default wait is 50 ms, set by the elisp variable
>> w32-pipe-read-delay. Setting that to 0 gives:
>>
>> (pipe-torture-read "/Projects/emacs/emacs-24.3.94/src/xdisp.c")
>> 0.180000, 0.095000
>>
>> only a factor of 2 slower than command-line cat.
>>
>> w32-pipe-read-delay is a global variable. The comment in _sys_read_ahead
>> says there are problems with subprocess interaction when setting this to
>> 0 on some systems. If that is still true, we may need to change this to
>> a per-subprocess setting.
>>
>> In my real application, let-binding w32-pipe-read-delay for a short time
>> is possible, and a reasonable workaround.
>
> I think I will set that to -1, on the trunk, except on Windows 9X
> systems. That should cause the reader thread yield its time slice
> before returning. Can you see how this affects your use case?
That has essentially no effect when running on a multi-core machine; the
subprocess is scheduled separately.
> As for the effect of this on non-Windows 9X systems, I don't see the
> problem described in the comment with the "dir" command on Windows XP
> when I set this variable's value to zero. And running DOS programs
> from a w32 Emacs is much less probable use case these days, what with
> the proliferation of 64-bit Windows systems that don't have a DOS
> emulator. So I think we can safely make this value zero or -1 on
> modern systems.
Ok.
> Thanks for tracking this down.
You're welcome. Thanks for your work on Emacs for Windows!
--
-- Stephe
This bug report was last modified 10 years and 254 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.