GNU bug report logs - #18626
24.3.94; communication with subprocess is slow

Previous Next

Full log

Message #38 received at 18626 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Leake <stephen_leake <at> stephe-leake.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18626 <at> debbugs.gnu.org
Subject: Re: bug#18626: 24.3.94; communication with subprocess is slow
Date: Sun, 05 Oct 2014 13:19:18 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stephen Leake <stephen_leake <at> stephe-leake.org>
>> Cc: 18626 <at> debbugs.gnu.org
>> Date: Sun, 05 Oct 2014 08:41:08 -0500
>> 
>> (find-file "xdisp.c")
>> (pipe-torture
>> "/home/Projects/org.emacs.ada-mode.stephe-1/build/wisi/debug_counted"
>> "4096" "974230")
>> 
>> 0.344027
>> 
>> This is comparable to the time on Windows with a large buffer in the
>> subprocess. So apparently it is not using the same delay in
>> send_process. Or the IO system is providing a large buffer.
>
> Evidently, subprocess I/O is more efficient on GNU/Linux than it is on
> Windows.  Perhaps this is related to the fact that by default
> GNU/Linux uses PTYs for that, not pipes.  Did you try your experiments
> with process-connection-type bound to nil?

On Debian:

(setq process-connection-type nil)

(pipe-torture-read "/home/Projects/emacs/emacs-24.3.94/src/xdisp.c")
0.074980

no signficant change

(find-file "xdisp.c")
(pipe-torture
"/home/Projects/org.emacs.ada-mode.stephe-1/build/wisi/debug_counted"
"4096" "974230")

0.294485, 0.304046,  0.343767

(pipe-torture
"/home/Projects/org.emacs.ada-mode.stephe-1/build/wisi/debug_counted"
"40000" "974230")
0.341241, 0.342165

Slower than pty, but much faster than Windows, and still independent of
subprocess read buffer size.


(setq process-connection-type nil) also eliminates the line-by-line
read; for a buffer size of 4096, Read returns 4096 until the end of the
text. For a buffer size of 40000, Read returns 40000 or 25536 until the
end of the text. (+ 40000 25536) = 65536, which makes sense for the
default pipe buffer size.

Given a send_process delay of 0.020 on EWOULD_BLOCK, and a buffer size
of 65536, the expected write time is (* 0.020 (/ 974230 65536)) = 0.28,
comparable to what we see.

Apparently pty's do the line by line send. Which makes sense for a
"psuedo-terminal". And they also apparently use a larger internal
buffer. 

-- 
-- Stephe

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.