bug#71355: 30.0.50; [PATCH] Improve performance of buffered output in Eshell

[Eli Zaretskii]

> Date: Wed, 5 Jun 2024 13:07:48 -0700
> Cc: 71355@debbugs.gnu.org, stefankangas@gmail.com
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 6/5/2024 11:58 AM, Eli Zaretskii wrote:
> > So now that we agree about this aspect, I ask again: wouldn't it make
> > sense to show the text to the user in smaller chunks?  2K characters
> > is 2 dozen lines, and I expect users to be somewhat unhappy about
> > being presented the text in such large chunks.  That's now what they
> > see when invoking 'cat' from the shell prompt outside Emacs.
> 
> Ok, I see what you mean. I think the thing users would be unhappy about 
> is "long" periods of time between display updates. (If we flush and/or 
> redisplay faster than the user's monitor refreshes, those updates are 
> wasted.)
> 
> For the kinds of output that Eshell's buffered-print is designed for, we 
> can get the text we want to print very quickly, so even with a buffer 
> size of 2048, we flush more than 60 times a second (testing with "cat" 
> and "ls" on a spinny disk). In situations where the buffering caused 
> unacceptable delays, a command would either a) not use buffered output 
> or b) manually flush at opportune times. I'm not sure those would come 
> up in practice though.
> 
> Ultimately, in the cases where Eshell does buffered-printing now, the 
> thing that limits the user seeing updates is the redisplay throttle, not 
> the buffer size.
> 
> A smarter version of 'eshell-buffered-print' could flush before the 
> buffer was full if enough time has passed, but that would add complexity 
> without a lot of immediate benefit. (For example, would we set up a 
> timer to flush? I'm not sure how that would interact with the rest of 
> this code, which is all synchronous.)

My main point is that 'cat' is used to show the contents of a file to
the user, so the assumption is that the user _wants_ to see that
stuff.  So having the stuff flash before user's eyes in an instant is
not necessarily the best idea, even though it is faster, and thus
performance-wise we win.

If the above is agreed, and you still think 2K characters is the best
default value, I'm fine with that.