Reducing cache/buffer for faster display

[Hans Mulder]

On 29/09/12 02:20:50, Rikishi42 wrote:
> On 2012-09-28, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
>> On Thu, 27 Sep 2012 22:25:39 +0000 (UTC), John Gordon <gordon at panix.com>
>> declaimed the following in gmane.comp.python.general:
>>
>>>
>>> Isn't terminal output line-buffered?  I don't understand why there would
>>> be an output delay.  (Unless the "\r" is messing things up...)
>>
>> 	It's the trailing ,		The \r is being used to reset to the
>> beginning of the console line, but the comma "says" more output for
>> /this/ line will be coming... So no output until explicitly flushed, or
>> a new-line is issued.
> 
> Well, the \r seems to be the problem, allright.
> But output was not completely blocked, just delayed a very long time.  
> 
> So perhaps flushing and a sending a newline aren't the only triggers for
> output.  Perhaps there's a maximum delay or a maximum cumulated size, and
> the output is flushed when such a limit is reached.

There's a maximum cumulated size; it's called the buffer size.
Output goes into a buffer, and when the buffer is full, it's
printed all at once.

One way to avoid it, is to use an unbuffered stream.

Another, more efficient, way to avoid it, is to invoke the
stream's .flush() method after writing to it.

> Anyway, that's mainly academic. I doubt there will be a correction to
> that behaviour. 

It's an optimization.  When it was invented, 40 years ago, it was a
really necessary to do this, to get something resembling performance.

The performance of a system without stream buffering would probably
be tolerable on modern hardware.  But the people maintaining Python
are unlikely to cut out buffering, because few people would benefit
(yours is pretty much the only use case where buffereing hurts) and
some would suffer (those who write many short strings to a disk file).


Hope this helps,

-- HansM