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

[Jim Porter <jporterbugs@gmail.com>]

On 6/5/2024 10:57 AM, Eli Zaretskii wrote:
> I think we are miscommunicating.  I wasn't talking about performance,
> I was talking about the fact that I don't see text delivered to the
> screen in chunks.  You said that the current code sends text to the
> screen in chunks of 5 lines, and that therefore using the value 128 is
> almost the same.

You had asked about changing the buffer size; in my initial explanation, 
I was just trying to explain my reasoning for why a larger buffer size 
improves the overall execution time. So I was only talking about the 
performance (the redisplay changes are mostly independent from the 
buffer size setting, since I throttle the redisplays by time).

To be more precise though: the current code writes text into the 
*buffer* in chunks of 5 lines. (That text will end up on the screen at 
the next redisplay, whenever that is.) With my patch, if I set the 
buffer size to 128, it will write text into the buffer every 128 chars, 
which results in a similar number of write operations as before the 
patch. Since those write operations are what makes the current code 
slow, a 128-char buffer with my patch is similarly slow.

> But at least part of your patch calls redisplay
> after each chunk (AFAIU), something that is not done with the current
> code.  So I expect the effect to be a difference in behavior, whereby
> test appears on the screen in chunks, and the user does not need to
> wait till all of it is sent before he/she sees anything at all
> displayed.

Correct. The redisplay logic is a new behavior, and not *directly* a 
part of the performance improvements I made by increasing the buffer 
size. On the contrary, I added the redisplay logic because the buffer 
size improvements made the total execution time so much better that I 
felt Eshell could now afford the extra cost of redisplaying periodically 
for these commands.