Re: Understanding filter function calls

[Karthik Chikmagalur]

> ... seems that TeXLive 2023 creates differently sized chunks of output?
> Could you try to buffer these using, for example, "dd", to see whether
> that makes a difference?

Thank you for the suggestion.  The problem appears to be simpler than
varying chunk sizes.  I had a closer look at the stdout from the two
versions of dvisvgm and it turns out they are not, in fact, identical.

On a large Org file, TeXLive 2023's dvisvgm stdout is 2521 lines to
TeXLive 2022's 1520.  This difference is explainable by some extra
information that dvisvgm prints per generated SVG image in the former
case:

TeXLive 2023:
-------8<--------
processing page 2
  computing extents based on data set by preview package (version 13.1)
  width=5.520849pt, height=6.944447pt, depth=0pt
  graphic size: 5.520849pt x 6.944447pt (1.940357mm x 2.440694mm)
  output written to test-000000002.svg
-------8<--------

TeXLive 2022:
-------8<--------
processing page 2
  graphic size: 18.524351pt x 10pt (6.510565mm x 3.514598mm)
  output written to test-000000002.svg
-------8<--------

Multiply the above blocks by 600, and that explains the large difference
in the sizes of the stdout.

It does not take any longer for the filter function to run on each
invocation.  The problem is that The filter in Emacs is called with
about 4KB of new text every time, and these calls are spaced out evenly
in time, so Emacs takes longer to get around to parsing the stdout with
TeXLive 2023.

The dvisvgm process is thus bottlenecked by Emacs.  I can imagine a few
different ways to fix this, but I don't know how to do them:

1.  Reduce the duration between successive calls of the filter function.
Is this configurable in Emacs?  I don't see anything relevant in the
manual sections on accepting output from processes or filter functions.

2.  Enlarge the buffer or "pipe" connecting dvisvgm to Emacs.  This
stream buffer appears to be set to 4KB.  Since dvisvgm produces far more
output (to stdout) than this between two successive instances of Emacs
accepting process output, widening the pipe should relieve this
pressure.  I tried tweaking `read-process-output-max' but this doesn't
help.

3.  Get dvisvgm to generate less verbose output.  Unfortunately this is
not configurable at the level of granularity that we need.  We can't
turn it off completely either since we rely on certain strings in the
process stdout to update the LaTeX preview state in Org buffers.

Any ideas on how to avoid this throttling would be appreciated.

Karthik