[slime-devel] Re: patchlets on buffering.
Helmut Eller
heller at common-lisp.net
Fri Nov 11 23:20:56 UTC 2005
* Mario S. Mommer [2005-11-11 18:16+0100] writes:
> Fred Gilham <gilham at csl.sri.com> writes:
>>> By default, the connection between the lisp and the slime repl is
>>> buffered. I would like to propose to have it unbuffered. on the
>>> grounds that if the user has a (format t ...), he/she probably wants
>>> the message to appear immediately on the screen :-)
>>
>> Isn't the proper way to make the message appear immediately to use a
>> (force-output) or a (format t "....~%")?
>
> One could argue about that. But the fact is that if the program makes
> any output, for whatever reason, and it is directed at a console with
> a human in front, it makes little sense to keep it in the buffer until
> that buffer is full.
It's a tradeoff between efficient bulk output or immediate response.
Currently SLIME offers the following options:
- with a multi-threaded lisp, full buffering is clearly the right
choice, because it's easy to spawn a thread to flush buffers a few
times per second. So all this is a non-issue with OpenMCL,
Allegro, Lispworks, and threaded SBCL.
- with *use-dedicated-output-stream* = t you get a fully buffered
stream.
- for *use-dedicated-output-stream* = nil we use line buffering with
a short delay, i.e. the buffer is flushed on newlines, but only if
it wasn't flushed 20ms before.
I going to change that so that *use-dedicated-output-stream* = t will
use an unbuffered stream by default, but make that customizable with
*dedicated-output-stream-buffering*.
On the efficiency side, there doesn't seem to much of a difference
between full and no buffering. At least not with the simpleminded
`M-x slime-io-speed-test'.
I note however that *use-dedicated-output-stream* = nil is faster than
the dedicated stream with certain Lisps, e.g. for CLISP and Lispworks
and not much slower for CMUCL (2-3 times slower). Of course the
current buffering scheme for the non-dedicated variant doesn't pass
the "(dotimes (i 10) (princ i) (sleep 1))" test, but I'm now seriously
thinking about removing the dedicated output stream.
Helmut.
More information about the slime-devel
mailing list