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

[Stefan Kangas <stefankangas@gmail.com>]

Jim Porter <jporterbugs@gmail.com> writes:

>>> +(defcustom eshell-buffered-print-size 2048
>>> +  "The size of the print queue in characters, for doing buffered printing.
>>>   This is basically a speed enhancement, to avoid blocking the Lisp code
>>>   from executing while Emacs is redisplaying."
>>
>> How did you decide on this value?
>
> Basically, I tried a few different command invocations that normally
> take a while (the main ones being "cat config.log" and "ls -Al
> /usr/bin") and scaled up the value by factors of two until I stopped
> seeing any major perf improvements. (Larger values are faster still, but
> not by a whole lot.)

FWIW, I've experimented a bit on my machine, and I see the following
using the command "time cat config.log" from an initially empty eshell
buffer:

| eshell-buffered-print-size | secs       |       |
|----------------------------+------------+-------|
|                        256 | 1.922 secs |     1 |
|                        512 | 1.413 secs |  0.74 |
|                       1024 | 1.065 secs |  0.55 |
|                       2048 | 0.996 secs |  0.52 |
|                       4096 | 0.860 secs |  0.45 |
|                       8192 | 0.835 secs |  0.43 |
|                      16384 | 0.829 secs |  0.43 |

To me, these numbers seem to suggest that, at least on this system,
there is a sweet spot around 4096, but 2048 admittedly does already get
us most of the way there.  However, going above 8192 doesn't lead to any
appreciable speedup.  This is on a fast M2 machine; it would be
interesting to see some experiments on slower machines as well.

I'm assuming that we don't want to set it to some arbitrarily large
number, but do we expect any adverse affects from choosing a slightly
higher value?  If not, is there a case to be made for choosing 4096 as
the default?