* Mario S. Mommer [2005-11-11 18:16+0100] writes:
Fred Gilham gilham@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.