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/
