M. Anton Ertl (firstname.lastname@example.org)
The standard does not specify whether buffering is allowed for words dealing with the user input and output devices, and the file words. The existence of
FLUSH-FILEindicates that buffering is allowed to some extent.
No buffering is allowed for the user input device. No buffering is on the user output device, if it is a terminal. Buffering is allowed for the user output device, if it is no terminal (e.g., a file), and for the file wordset. The amount of buffering is system-defined.the file-id for the current user output device
OUTFILE-ID( -- file-id ) file-ext
Allowing buffering for non-terminal user output device may increase the performance for filters.
Flushing the user output device can be achieved with
Gforth <= 0.3.0 used no buffering for
KEY, line buffering for outputting to a terminal, and block buffering for outputting on non-terminals. Several users complained about the buffering for the user output device (they used a terminal), so starting with 0.4.0 we use no buffering for the user output device if it is a terminal. Nobody has complained about the file buffering.
Gforth has implemented
OUTFILE-IDsince 0.2, and it is in use (mainly internally).
Experiments with a filter we had on Gforth under Linux showed no significant performance advantage for buffering the user output device. We should repeat this experiment with a more I/O-intensive filter (the one we measured produced only 94KB of output).
Another experiment with Gforth under Linux-Alpha resulted in a worst-case slow-down factor of 25 for turning off buffering. The benchmark used in this experiment was:: foo 10000000 0 +do [char] x emit loop ;