Re: Why does adding a useless copy-sequence and discarding the result make my ELisp 40 times faster?

[Clément Pit-Claudel]

On 2017-03-25 12:38, Andreas Politz wrote:
> Clément Pit-Claudel <address@hidden> writes:
> 
>> On 2017-03-25 06:38, Andreas Politz wrote:
>>> The limiting factor may also be python itself...
>>>
>>> ;; python2
>>> ((0.114342188 0 0.0)
>>>  (0.715895279 0 0.0)
>>>  (2.120252213 0 0.0)
>>>  (1.02429565 0 0.0))
>>>
>>> ;; bash = "while read;do : ;done"
>>> ((2.008305836 0 0.0)
>>>  (1.999825023 0 0.0)
>>>  (2.026715753 0 0.0)
>>>  (2.060320318 0 0.0))
>>
>> Interesting! But doesn't this just show that bash is uniformly slow?
> 
> This suggests to me, that the deciding factor in these numbers is python
> and not Emacs.
> 
> Maybe it has a read buffer of a certain size, let's say 65536 ;O), and
> if that buffer runs out of space, things get stalled.

The thing is, I reproduced these numbers with cat and a simple C program, so 
it's not python itself.  But indeed the default pipe buffer size on Linux is 
65536 bytes, so there's certainly something going on with buffering at the 
65536 (2^16)/65537 (2^16 + 1) threshold.

That doesn't explain observation 3 though (why is sending many small messages 
so much faster than 1 large one), nor observation 1 (why is the program without 
sleep or copy-sequence so slow?). Worse, Emacs' docs for process-send-string 
claims that messages larger than 500 bytes will be split.

Clément.