# 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. As 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 '13 at 7:06
• Could someone clarify what is meant by 'externalizing graphics' and 'pre-compiling the preamble'? Perhaps as an answer below... – dardisco Jan 18 '17 at 0:51
• @dardisco "externalize graphics": tell TikZ to write any graphics into an external file, so that subsequent compilations can simply include the file (tex.stackexchange.com/q/477859/107497). "pre-compile the preamble": dump TeX's preamble to file.fmt, so that subsequent compilations can quickly read in that file and start from there instead of going through all of the newdefs (tex.stackexchange.com/q/79493/107497 and many links therein). – Teepeemm Jun 29 '19 at 19:51

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
• @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
• What do you mean by "nice speedup"? My compilation got faster in the 10% range. Not bad but also not really life changing :/ – Christian Dec 12 '12 at 16:56

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 ... :-) – user2478 Jan 12 '11 at 13:07
• 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 ... – user2478 Feb 16 '11 at 18:45
• Just information: -draftmode can be used only for pdflatex and latex. xelatex has no such an option. – kiss my armpit Mar 14 '12 at 8:29
• Making this work in TexStudio: Go to Settings > User Commands, add pdflatex -draftmode %.tex | biber % --output-safechars | pdflatex -draftmode %.tex | pdflatex -synctex=1 %.tex | txs:///view – n1000 Sep 24 '16 at 15:07

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? – kiss my armpit Mar 14 '12 at 8:03
• @DamienWalters: batchmode is faster. – Leo Liu Mar 14 '12 at 9:43
• – alfC Sep 17 '14 at 3:47

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 computer with a faster CPU.

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. – Patrick Häcker May 21 '13 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 '13 at 7:05

If you are using XeLaTeX, a substantial amount of time is spent gzipping data with highest compression (9) in the xdvipdfmx command.

~$xdvipdfmx --help … -z number Set zlib compression level (0-9) [9] …  For me, on a 90 page document: ~$ time xelatex -interaction=nonstopmode Thesis.tex
…
real    0m6.056s
~$ls -lh Thesis.pdf … 6,0M … Thesis.pdf  Without compression: ~$ time xelatex -interaction=nonstopmode -output-driver='xdvipdfmx -z0' Thesis.tex
…
real    0m2.417s
~$ls -lh Thesis.pdf … 142M … Thesis.pdf  That is ~60% time saved but 23× bigger. Ok, some compression is clearly needed. My sweet spot: ~$ time xelatex -interaction=nonstopmode -output-driver='xdvipdfmx -z3' Thesis.tex
…
real    0m2.957s
~$ls -lh Thesis.pdf … 6,9M … Thesis.pdf  That is 0.5s for compression or some 16% of the total time, as opposed to the majority of the time with default settings. I can usually live well with the 15% bigger file size. Of course, it does make sense to use -z9 for the final build. I did not use XeTeX but assume the same scenario applies. • I am adding -file-line-error -synctex=1  to your suggestions above, like this: xelatex -interaction=nonstopmode -file-line-error -synctex=1 -output-driver="xdvipdfmx -z0" "$1", which is allowing me to have the speed gain while retaining synctex advantages (NB: the syntax I have here with "$1" is TeXShop's) – Juan del Acebo Sep 22 '18 at 3:21 • Note that xdvipdfmx -z9 is faster and results in a smaller file than using xdvipdfmx -z0 together with optpdf. To increase the speed even more I also use xelatex -interaction=batchmode -draftmode -no-pdf for the first time(s) and then xdvipdfmx -z9 to convert the xdy to pdf. (n × xelatex -no-pdf + xdvipdfmx vs. (n - 1) × xelatex -no-pdf + xelatex does not really make a difference in my example) – miile7 Jul 10 '19 at 8:19 • very nice answer. – Enthusiastic Engineer Jan 13 at 9:36 Here is a tip: Beamer+graphics is a 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. – user2478 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? – kiss my armpit 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! – user2478 Mar 14 '12 at 9:51 • Using imagemagick's convert program in a script with the -density and -quality option set to a low value is probably an easy, cross-platform, and free way to do this. – bbarker Apr 21 '14 at 17:31 • Specifically, I use $ convert figure.png -resize 20% ./preview/figure.png. – Evgeni Sergeev Jul 13 '17 at 8:43

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.

• Super helpful for debugging also. For us beginners, could you perhaps expand a little on what's happening here/ how this works? – dardisco Jan 18 '17 at 0:49
• \iffalse ... \fi evaluates the code in ... if False evaluates to True (like if (false) { ... } in C-like languages), so it effectively "deactivates" the code contained inside and prevents TeX from compiling it. – Soham Chowdhury Jul 18 '17 at 6:41

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.

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.