# Speeding up LaTeX compilation

Usually I don't mind about LaTeX's compilation speed, because a paper of less than 20 pages is compiled rather fast. However, I am working on a large document - A report with more than 80 pages. Compilation times are starting to slow me down. I saw the couple of answers here on this topic, but most of my graphics are external and I don't use Tikz. In a matter of fact, I'm not sure what's slowing the compilation down, other than the amount of text and required layout.

1. What's your best speeding-tex-up trick, other than externalizing graphics and pre-compiling the preamble?
2. How can I know what's slowing TeX down?
-
Forgive me if I'm totally of-base, but isn't this a community-wiki type of question? Or am I wrong? –  Canageek Oct 3 '11 at 3:47
–  Daniel Oct 2 at 7:06

large documents start with pages >500 ... Create a script which runs:

pdflatex -draftmode file
bibtex file # or biber
makeindex file.idx # if needed
makeindex -s style.gls ...# for glossary if needed
pdflatex -draftmode file
pdflatex file


The compilation can now be speedup if you run bibtex/makeindex/... only when there were changes in this area. Can be detected with a diff for the auxiliary files.

-
Couldn't the second pdflatex run also use -draftmode? –  Philipp Jan 12 '11 at 12:47
@Philipp: yes, we can ... :-) –  Herbert Jan 12 '11 at 13:07
Even better would be creating a Makefile. That way you can detect if eg makeindex has to be run. eg gd.tuwien.ac.at/pub/publishing/latex/CTAN/macros/latex/contrib/… –  johanvdw Feb 16 '11 at 18:29
you can it detect only for special cases, because I can define my own file extension and then yor Makefile cannot detect my use of makeindex or xindy or splitindex ... –  Herbert Feb 16 '11 at 18:45
That's obvious ... –  Herbert May 23 '12 at 12:11

Beware of Greeks bearing gifts... Apparently, the nice todonotes package that I used dragged Tikz along with it, and introduced a major slowdown. Switching to simple marginpars gave a nice speedup. It should be noted that this package is a performance Trojan horse.

-
+1 for the info about "todo". However, it would be best if you don't ask questions in your answers, so please remove the last sentence (and edit your question if you want to). –  Hendrik Vogt Jan 12 '11 at 11:00
@Little Bobby Tables, @Hendrik: Except that the information is incorrect: the todo package does not load tikz, although the todonotes package does. Please be careful when referring to packages by name, especially when the information is negative. –  Alan Munn Jan 12 '11 at 12:34
@Alan: Oops, thanks a lot for the correction. (Incidentally, only the first "@" in a comment notifies a user. So in your case, "@Hendrik, @Little Bobby Tables" would have been the better order; this would have notified both of us since the author of the answer gets notified anyway.) –  Hendrik Vogt Jan 12 '11 at 13:07
@Hendrik Thanks. How the whole "@" thing works is a bit mysterious anyway. Do I have to use the full name or will this get to you with just "@Hendrik"? –  Alan Munn Jan 12 '11 at 13:29
@Alan: I've asked this on meta some time ago; there you can find the full explanation. –  Hendrik Vogt Jan 12 '11 at 13:33

The most useful trick I know is: do not do textual changes and layout changes at the same time, but make a clear division between them.

I first fix up all the text issues (there is hardly any need to recompile during that cycle) and only afterwards worry about layout and page breaks. The separation means that in the second cycle, I can usually tackle more than one display problem simultaneously.

The second most useful trick I know is: buy a faster computer with more RAM.

Precompilation of the header will only save you some startup time, but does nothing for consecutive pages, so the effect diminishes as your document grows.

-
I agree on the separation between typing text with rare compilations, and then doing the layout several bits at a time. When I remember to apply it, it frees my mind a lot from all the thoughts about layout. –  Bruno Le Floch Jan 12 '11 at 12:44
Note, that adding more RAM will normally not increase TeX's speed. I just tested a not-too-small document with many packages and had a 49 MB RAM usage of the pdflatex process (peak value) plus 47 MB file cache usage after the compilation process (I dropped the caches before the measurements). So 100 MB of free memory when the OS and all the other applications are loaded seems to be enough for most cases. The only thing that does matter is the single-core (integer) cpu speed. –  MMM May 21 at 12:35
The RAM hint is more than misleading and should be removed! pdflatex is a CPU–bound process. See Tips for choosing hardware for best latex compile performance –  Daniel Oct 2 at 7:05

I think the most effective way to save time is to avoid compiling the document time and time again. Compilations are often not really needed, when we change several words or a simple equation.

For large documents, we can split them into small pieces using \include command. Then \includeonly helps us to compile the only piece we are interested in, leaving the whole compilation to the last stage.

For complex tables or graphs made by TeX, put them into seperate TeX files first to verify the code, then add them to the document.

Sometimes compilation options may affect the speed. pdflatex -interaction=batchmode foo is often faster than pdflatex foo, this avoid scrolling informations. There may be more, say, xelatex -no-pdf foo is faster than xelatex foo, if it isn't the last round.

-
Which one will run faster, with batchmode or nonstopmode? –  Stiff Jokes Mar 14 '12 at 8:03
@DamienWalters: batchmode is faster. –  Leo Liu Mar 14 '12 at 9:43
Okay. Thank you. –  Stiff Jokes Mar 14 '12 at 9:44

Here is a tip:

Beamer+graphics is a another time-consuming combination that I revisit every now and then when preparing presentations. What I do is keep all my graphics in a directory images that is actually a symbolic link to either images-hires or images-lowres. The latter is a script-generated directory with a copy of each image in image-hires but with a considerable resize transformation.

This process could be even smarter with a small preamble that checks the draft option of the document class and sets the correct path with \graphicspath. But I haven't done it because I didn't know this macro before and I am not very skilled at LaTeX/TeX macros and magics.

-
With pdflatex -draftmode file the images are not read which is useful until the very last pdflatex run. –  Herbert Jan 12 '11 at 18:51
@Herbert: Is there a difference between passing -draftmode to pdflatex used to compile an input file without draft option passed to \documentclass and passing draft to \documentclass compiled with pdflatex invoked without -draftmode option? –  Stiff Jokes Mar 14 '12 at 7:21
the draft option is far different from using the option -draftmode. The latter didn't produce a pdf file! –  Herbert Mar 14 '12 at 9:51
@Herbert: I see. Thanks. –  Stiff Jokes Mar 14 '12 at 12:25

Regarding your first question: the most noticeable speedup I've witnessed so far can be achieved by compiling to DVI instead of PDF. You may not be able to do that depending on the packages you use, however, but you could give it a try.

-
Doing so already, thanks. –  Little Bobby Tables Jan 12 '11 at 15:36

## Math Accents

Math accents can slow down a compilation. To speed up a document with many of these you can use the \accentedsymbol command defined in amsxtra subpackage of the amslatex package. In the example below, \vx can be used for \vect{x} but will not take the time required to place the accents (arrows on bold symbols for example). Note that since the typesetting is done out of context, some issues can arise (the size will not be small in a superscript for example), so for the final version you should redefine \accentedsymbol to simply define a macro that will get expanded everywhere in context.

\usepackage{amsxtra}
%\renewcommand\accentedsymbol[2]{\def#1{#2}}  % Uncomment for final version
\accentedsymbol{\vx}{\vect{x}}


Note that there are limits to how many symbols you can store this way.

## Kpathsea

Not really a LaTeX issue per se, but kpathsea can be a huge performance hit if you are recursively searching directories and/or your ls-R databases are not up-to-date. You can see what it is doing by setting

export KPATHSEA_DEBUG=1


before you run latex. If it is searching many places, then this can be a huge slow-down. Details can be found in the manual. (I had a huge performance hit when I accidentally recursively linked a texmf tree deep within another tree for a package I was writing.)

-

Don't load inputenc and/or fontenc if they are not necessarily needed because:

The inputenc–fontenc combination seems slow and cumbersome, but it’s safe.

cited from Why bother with inputenc and fontenc?

-
This solution is only really gonna be helpful for English documents; as soon as you use about any character outside of the ASCII range, you'll need these packages. –  doncherry Oct 3 '12 at 0:46

Personally, I use the -interaction=batchmode option to prevent verbose output. Also, for the first runs (except the last), you can use -draftmode option:

-draftmode
Sets \pdfdraftmode so pdfTeX doesn't write a PDF and doesn't read
any included images, thus speeding up execution.


In case of error (\$? -ne 0), it is sufficient to tail the log file. You can see the full code on Github.

-
If you don't generate a PDF how do you preview the layout? –  lhf Oct 3 '12 at 2:27

When you need to iterate on something (say, the formatting of an equation), a quick and dirty but very effective trick is to comment out the bulk of the document using:

\iffalse

all the stuff you don't need to compile every time...

\fi

then you can focus in on the particular section you are working on, until you've got it just right with a tight edit/compile loop.

Then uncomment the rest of the document.

-