[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