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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 05 Jun 2024 19:51:39 +0300

> Date: Wed, 5 Jun 2024 09:42:43 -0700
> Cc: [email-masked], [email-masked]
> From: Jim Porter <[email-masked]>
> 
> On 6/5/2024 5:06 AM, Eli Zaretskii wrote:
> > Is 2K indeed the optimal size?  It is about 25 80-column lines, which
> > is quite a lot.  "Normal" shells send output to the screen in smaller
> > chunks.  How about 128 instead? or maybe some small multiple of the
> > line length, like 1 or 2?
> 
> Yes, I believe 2k is the optimal size, or close to it. Trying a value of 
> 128 results in basically no change in performance from baseline. That 
> makes sense to me, since 128 is actually fairly close to the old value 
> for this buffering (which was five *lines*[1]; the old code measured 
> this differently).

That's strange, because I see no output at all until all of it is
available and showsn, and I thought you said the same in your OP?

> In starting on this work, I compared to the amount of data that I get 
> each time a child process filter is called; that's normally 4095 bytes 
> in my tests. Then I started a bit lower (512) and gradually doubled the 
> buffer size until I was able to get most of the performance benefit.

So why do I see only all of it, in one go?  I see this both on Windows
and on GNU/Linux, btw.