Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

speeding up the build of variants #10

Open
FAMILIAR-project opened this issue Jun 24, 2020 · 3 comments
Open

speeding up the build of variants #10

FAMILIAR-project opened this issue Jun 24, 2020 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@FAMILIAR-project
Copy link
Contributor

FAMILIAR-project/varylatex#7

there are some discussions here and there: https://tex.stackexchange.com/questions/273997/incremental-build-of-large-document
https://tex.stackexchange.com/questions/8791/speeding-up-latex-compilation
the "draft" trick or "includeonly" is quite interesting

@c-a-m-o
Copy link
Collaborator

c-a-m-o commented Jun 24, 2020

Performance improved in commit fe19e7d
It may be difficult to use \includeonly in the example because the included files are added using \input (the difference seems to be that \input is the only one that does not add a page break) instead of \include.
The improvement that could be made is adding the -interaction=batchmodeoption to pdflatex. It prevents interruptions thus making the compilation faster.
The downside of this is that we can no longer use latexmk but another upside of this is that we only have to generate the bibliography once for all the compilations.
For the example document, we got from about 1.2s to 0.29s on average for each pdf generation.

@FAMILIAR-project
Copy link
Contributor Author

FAMILIAR-project commented Jun 24, 2020

wow impressive! thanks.

maybe we should think about providing some options to varylatex for customizing the latex command(s) to use...
but by default I like to have a batchmode to speed up everything ;)

another downside of batchmode is that maybe some variants of the LaTeX don't compile and we won't detect them...
but we can trade safety for performance ;)

can you measure the time it takes to compile and store the value in the CSV for each variant #3? It can be interesting at some points.

there is also the package "draft" that does not depict figures in the PDF... can save some time as well.
I have also read discussions about compressing the quality of images just to speed up the compilation. It seem specific to some cases (like big PhD manuscripts), but why not having such a preprocess (as an option of varylatex) if it's worth.

In general, we should assess our speed improvements on various cases, beyond FSE one, but it's definitely future work.
At the end we will provide a default "mode" of varylatex that is the best for most of the cases.

@FAMILIAR-project FAMILIAR-project added the enhancement New feature or request label Jun 24, 2020
@FAMILIAR-project
Copy link
Contributor Author

FAMILIAR-project commented Jun 25, 2020

https://www.systutorials.com/docs/linux/man/1-rubber/
not sure it's the most up-to-date system

anyway, there is a --cache option (maybe interesting)
and a --only option: we can envision to compile what's "common" once and for all, and then the variable part...
it's much more advanced use case/idea, will see if we address it in the future

edit: https://github.com/petrhosek/rubber

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants