lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use GhostScript API instead of forking (issue 548030043 by address@h


From: jonas . hahnfeld
Subject: Re: Use GhostScript API instead of forking (issue 548030043 by address@hidden)
Date: Fri, 01 May 2020 04:35:26 -0700

On 2020/05/01 11:31:23, hanwenn wrote:
> On Fri, May 1, 2020 at 1:18 PM <mailto:address@hidden>
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

[Prev in Thread] Current Thread [Next in Thread]