Re: Understanding filter function calls

[Eli Zaretskii <eliz@gnu.org>]

> From: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
> Cc: jschmidt4gnu@vodafonemail.de, emacs-devel@gnu.org
> Date: Sat, 29 Jul 2023 15:16:49 -0700
> 
> 1. A pty connection + adaptive-read is the slowest (by a fair bit).  All
> other combinations are equally fast.

It is a general recommendation to use pipes when the subprocess
produces large amounts of output, and Emacs doesn't need to emulate
interactive behavior vis-a-vis that subprocess' program.  PTYs are
less pertinent for high-throughput applications.

> 2. Despite the value of read-process-output-max, a pty connection calls
> the filter function with at most 4 KB of data most of the time.

I think this is a limitation of the Linux kernel's implementation of
PTYs.

> 3. With a pipe connection, we indeed see reads of up to
> read-process-output-max (64 KB in my tests).

FTR: if someone has to do something similar on MS-Windows, they will
need to enlarge the value of w32-pipe-buffer-size accordingly.

> >> But I was able to use Emacs normally (typing, calling M-x etc) when the
> >> previews were being updated, which is great.  So I'm not sure what the
> >> performance implications are here.
> >
> > You don't want to rewind the long history of this and re-live all the
> > issues we experienced and investigated before we settled on the
> > current default.  If you can solve this particular problem by binding
> > the variable to nil around the code which invokes dvisvgm, that is all
> > I suggest doing.
> 
> I agree that it's not important, I was just curious since I didn't
> notice any immediate issues.

the issues are not always immediate, and don't became apparent until
you see enough subprocesses of different kinds, throughputs, and
behavioral aspects.  In the long history of this variable, its default
changed at least twice, AFAIR.