# Latex compilers with parallel support

Are there any latex compilers which support parallel compilation for a book? For example, the chapters in a multi-part latex document can potentially be compiled on separate cores to speed up compilation:

\begin{document}
\pagestyle{plain}
\onehalfspacing
\frontmatter
\include{title}
\include{abstract}

\mainmatter

\include{chapter1}
\include{chapter2}
...
\include{chapterN}

\begin{appendices}
\include{appendices}
\end{appendices}

\backmatter
\bibliographystyle{unsrt}
\bibliography{references}

\end{document}


## migrated from stackoverflow.comMay 30 '14 at 18:01

This question came from our site for professional and enthusiast programmers.

There is probably no latex compiler which supports parallel compilation.

The short reason is: The way latex typesets documents is essential linear. If latex would typeset different document parts in parallel, they would need to be merged at the compilation. However to get the same result as in the non-parallel case, you would need to have a compilation run over the already typeset parts to connect them properly (pagebreaks, numbering of table, etc.). Hence you end up with probably the same compilation time or worse than before.

• If you assume that chapters start on new pages, it would be (theoretically) advantageous to compile the chapters in parallel and add the header afterwards. Furthermore, there could be a parallel "draft compile" option, which is every fast, but does not guarantee optimal page break. So I the OP's approach is not absurd. – JF Meier Nov 3 '15 at 15:49
• I wouldn't say that the OP's approach is absurd. But it looks like that nobody was/is really sufficiently interested in this kind of option to justify programming it. Hence if this option is needed, then somebody needs to take the source code of TeX and try to implement it. – kristjan Nov 4 '15 at 19:31
• The first sentence here is nonsense. Just because it's difficult doesn't mean it's impossible or even that "should not" exist. There are standard techniques in compilers for dealing with dependencies and re-doing whatever work is necessary (branch prediction, speculative execution etc). There's a huge difference between what the comment says (nobody is sufficiently interested, etc.) and what the answer says ("there should not be any…"). – ShreevatsaR Nov 22 '17 at 20:10

As an example, the page number are not independent usually. The page numbers of the second chapter depends on the page numbers of the first. Also there can be references, index entries, ...

If all relevant counters are reset at the start of a new chapter (page, figure, table, equation, ...), then \include/\includeonly can be tried to compile the chapters independently. E.g. the chapters are in separate files, input by \include:

% test.tex
\documentclass{...}
...
\begin{document}
\include{chap1}
\include{chap2}
...
\end{document}


\includeonly can be given on the command line (-draftmode is described below):

pdflatex -draftmode '\includeonly{chap1}\input{test}'
pdflatex -draftmode '\includeonly{chap2}\input{test}'
...


and in the final run(s), the complete document is set with all chapters:

pdflatex test


to get the complete output file with all chapters. Otherwise the merging of chapter PDFs is non-trivial because of inter-chapter references, bookmarks, ...

The index and bibliography are usually generated independently. Thus makeindex/xindy or bibtex/biber can be called in two parallel processes.

A (quite) small amount of time can be saved by using -draftmode for the first LaTeX runs except the final. With option -draftmode the output PDF/DVI file is not written, but all auxiliary files (.aux, .toc, ...) are created as usual.

• There are lots of opportunities for parallel compilation. The TikZ pictures are one of them and it is TikZ and derived packages that usually take a long time to compile. The only real reason why this does not exist, is that Knut did not have an SMP machine at his disposal when designing TeX. – ajeh Jan 31 '17 at 22:42
• @ajeh Well, I don't think that's quite true. I mean: he can hardly have had TikZ pictures to externalise. A lot of the externalisation stuff depends on code which comes much later, surely. I agree that he didn't have multiple-cores available. I wouldn't say that's the 'only' reason, though. – cfr Dec 11 '17 at 1:10