Re: 22.1.50; insert-file-contents is slow under tramp

[David Kastrup]

Michael Albinus <address@hidden> writes:

> Richard Stallman <address@hidden> writes:
>
>>     Same old scheduler problem that prompted both of
>>
>>     w32-pipe-read-delay
>>     process-adaptive-read-buffering
>>
>>     Maybe you should try setting process-adaptive-read-buffering to a
>>     non-nil non-t value?
>>
>> Should the defaults for any of these be changed?
>
> Strange. On my test system, the default value for
> process-adaptive-read-buffering is t. Using this, or 'keep, I have
> very poor access time. Changing it to nil, the access time is
> decreased remarkable.

So it would appear that it needs to go under the knife again.  The use
case for which it was written is doing small-chunked output on a
single processor machine read by Emacs filters.  In that case, the
default "context switch whenever possible" strategy of "modern"
operating systems leads to small chunks being processed by a filter,
and in the worst case, redisplay every time (when the data generating
process does not get CPU because Emacs is not preempted, no new input
can arrive until Emacs idles).  Sort of a worst use case is using
something like

hexdump -v /dev/zero|dd obs=1

inside of a shell window.  One actually can see this also in xterms,
though the effects are more drastic on Emacs.  Multiprocessor machines
can make progress in the output generation even when Emacs is not
idle, so the problem is not apparent there.  The new "completely fair
scheduler" slated for Linux 2.6.23 will supposedly also do the trick.

Nevertheless, I think we should keep some sort of fix around, and this
means we need to get the rather awful degression out of tramp.  Of
course, reducing tramp's roundtrips would be one option, but
roundtrips are still necessary in many other applications and
protocols.

It is pretty certain that something is broken here: when writing to a
tty, the wait-before-read delay was supposed to get reset to zero.  So
roundtrip protocols were supposed to work just as fast as without
process-adaptive-read-buffering.

-- 
David Kastrup