On 2020/05/01 11:31:23, hanwenn wrote:
> On Fri, May 1, 2020 at 1:18 PM <mailto:jonas.hahnf...@gmail.com>
wrote:
> >
> >
> >
>
https://codereview.appspot.com/548030043/diff/583830043/lily/general-scheme.cc
> > File lily/general-scheme.cc (right):
> >
> >
>
https://codereview.appspot.com/548030043/diff/583830043/lily/general-scheme.cc#newcode783
> > lily/general-scheme.cc:783: command += "(" + ly_scm2string (input) +
")
> > run";
> > On 2020/05/01 06:42:43, hanwenn wrote:
> > > This doesn't hook very deeply into GS internals or how we arrange
the
> > page.
> > > Could we get the same speedup by putting the batching into an
> > encompassing .ps
> > > file, and calling GS on that file once?
> >
> > I think this would require substantial refactoring of how LilyPond
> > works. As far as I understand, currently each input file is handled
> > separately and temporary files are deleted after processing. To get
> > similar speedup, we have to reuse the interpreter for the complete
run
> > of LilyPond.
> 
> We can hide it behind a facade, in much the same way that your patch
> introduces hidden state. That would only work if we don't postprocess
> the GS output after it's generated, but IIRC, we don't do that.

No, but LilyPond deletes the temporary PS unless the user wants to have
it. This would also need to be deferred after the batching .ps has been
processed. Instead this patch keeps the processing where it was before
(right after producing the PS), it just saves the interpreter for reuse.

https://codereview.appspot.com/548030043/

Reply via email to