bug#66288: 29.1; Performance regression using pipe for subprocess

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 2 Oct 2023 14:22:06 -0400
> Cc: 66288@debbugs.gnu.org
> From: Chris Hanson <cph@chris-hanson.org>
> 
> > Finally, if you describe in plain English how xscheme.el reads
> > subprocess output at the stage where you see the slowdown, it might
> > give further ideas.  I'm not familiar with xscheme.el, and figuring
> > out which code gets executed when one runs "run-scheme" is not
> > trivial, so a detailed enough description might help.  Specifically,
> > how does xscheme.el decide how much of the subprocess's output to read
> > and display?
> 
> The process filter has one complexity: it looks for encoded commands 
> from the subprocess, which are of the form "ESC <char>" or "ESC <char> 
> <string> ESC", depending on the <char>.  There is a small state machine 
> to do that, which searches the output string for ESC using 
> `string-search'. In this case there are no commands embedded, so that 
> should not be relevant.
> 
> The ordinary text is inserted into the process buffer using standard 
> filter-output code, except it looks for BEL and translates that to 
> (beep) if found.  In this case there are no occurrences of BEL in the 
> output, so that's not relevant.  So, basically the output string is 
> passed to `insert', making sure that process mark and point are updated 
> appropriately.

Thanks.  It would be good to see the Lisp profiler results for your
recipes, in both versions of Emacs, to understand whether any of these
Lisp parts have anything to do with the issue.  (You say that these
aspects of the processing are not relevant, but maybe they have some
overhead even when the special characters and commands do not appear
in the output?)