# 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? Oct 3, 2011 at 3:47
• Oct 2, 2013 at 7:06
• Could someone clarify what is meant by 'externalizing graphics' and 'pre-compiling the preamble'? Perhaps as an answer below... Jan 18, 2017 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). Jun 29, 2019 at 19:51
• Related (speed up pandoc compilation): latex - Simple and fast PDF compilation with Pandoc - Stack Overflow Oct 23, 2021 at 14:22

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). Jan 12, 2011 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. Jan 12, 2011 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"? Jan 12, 2011 at 13:29
• @Alan: I've asked this on meta some time ago; there you can find the full explanation. Jan 12, 2011 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 :/ Dec 12, 2012 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? Jan 12, 2011 at 12:47
• @Philipp: yes, we can ... :-)
– user2478
Jan 12, 2011 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, 2011 at 18:45
• Just information: -draftmode can be used only for pdflatex and latex. xelatex has no such an option. Mar 14, 2012 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 Sep 24, 2016 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? Mar 14, 2012 at 8:03
• @DamienWalters: batchmode is faster. Mar 14, 2012 at 9:43
• – alfC
Sep 17, 2014 at 3:47
• I disagree with the first part of that advice. Frequent compilation is very much needed when working with Tex, mainly due to the possibility of introducing a syntax error/typo etc when writing which will be almost impossible to find, as the common ones result in non-local errors. Another reason is that the advice is irrelevant, as mostly frequent compilations will not be due to added text, but things like tweaking the bibliography, which requires dozens of lengthy compilations runs and can, therefore, take hours. Sep 9, 2021 at 22:54
• For \includeonly, an alternative is to use standalone package and compile the individual part instead of the whole document – the advantage is that you can use \input and don't have to break each section into a separate page. Nov 17, 2021 at 3:37

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) Sep 22, 2018 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) Jul 10, 2019 at 8:19 • There are also other ways to change the compression level, see xetex - prevent xelatex from compressing the output and tex.stackexchange.com/a/53252/250119 and luatex - LuaLaTeX: How to speed up PDF generation? - TeX - LaTeX Stack Exchange Nov 14, 2021 at 14:21 • latexmk -xelatex handles all the advice in this answer and comments to this answer: it compiles with -no-pdf by default, then once finished with the .xdv it then runs xdvipdfmx. 👍 Apr 25, 2022 at 23:00 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. Jan 12, 2011 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. May 21, 2013 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 Oct 2, 2013 at 7:05 • is it possible to compile latex using GPU? Jun 8, 2022 at 13:22 Although the original post is rather old, I just stumbled upon this issue myself with a 100+ pages project with lots of figures. If you're still working on the document and the resulting PDF file size is less important, you may try adding the following primitives at the beginning of your document \pdfcompresslevel=0 \pdfobjcompresslevel=0  This significantly increased the PDF file size for me, but in turn reduced compilation time to (not by) about 34%. If you're done editing and want to compile the final version, just comment out these lines. This is somehwat related to I have a name now's post, but doesn't require the command line and appears to be independent of whether you're using pdflatex or other engines. Best, r. • I think this one is dependent on PDF? I also left a comment under that post for method in other engines, one of them (claims to be) engine independent. tex.stackexchange.com/questions/8791/… Nov 17, 2021 at 3:33 • I tried this on a 450-page document, and made absolutely no difference. It is not figure-heavy, but uses tcolorbox in almost every page. Jan 5, 2022 at 18:11 • This reduces my compilation time from 10 seconds to to 1.5 seconds, albeit with a file size increase of 33 times. But still a very good timesaver! Jan 21, 2022 at 10:08 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, 2011 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? Mar 14, 2012 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, 2012 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. Apr 21, 2014 at 17:31 • Specifically, I use $ convert figure.png -resize 20% ./preview/figure.png. Jul 13, 2017 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? Jan 18, 2017 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. Jul 18, 2017 at 6:41
• For quick formatting of a smallish amount of source, in TeXShop you may use the Experiment menu command, which just compiles the text copied from the clipboard into the Experiment source window, but using the preamble of the root document. Jan 18 at 18:26

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.



I have a little tip:

If you want to include lots of figures, try to make them in vector graphics (.svg, .pdf, .ps), rather than raster graphics (.jpg, .png).

In my practice, a latex file containing 20 pages & 22 figures takes 56 seconds to compile when all figures are in .png, but only 4 seconds when I replace all of them with .pdf figures.

This may help people like me preparing latex draft for journal publication, since plots made with Python Matplotlib, IDL, Matlab, Origin or Excel can be easily exported in .pdf format.

I made a new Python script/module/package for this purpose.

https://github.com/user202729/tex-fast-recompile

(unlike other answers, this does not actually speed up the compilation, but it makes the PDF appear faster after the source code is edited)

I'll quote a section from the readme/documentation:

## How does it work?

The principle is very simple. Notice that while the user want fast refresh, the file does not change very frequently.

As such, we start the compiler before the file has changed to process the "preamble", then when the file changed we continue processing the rest of the file.

A graph for illustration:

Before:

(each * represents a file change, |--.--| represents a compilation where the . marks where the preamble processing is done)

+----------------------------------------------------> Time
*          *                *           *
|--.--|    |--.--|          |--.--|     |--.--|


After:

+----------------------------------------------------> Time
*          *                *           *
|--.--|--. --|--.           --|--.      --|


It can be easily seen that after the change, it only takes 2 instead of 5 time unit from when the file is saved to when the change is reflected in the PDF.

Note on other known methods: (mentioned in the comments etc., collected here for convenience)

There's this solution...

• only works on POSIX systems
• requires LuaLaTeX
• somewhat cumbersome (for now)
• requires shell-escape and manually install some Lua library
• may fail to work for weird reasons, or damage your computer

• real incremental compilation! (*)
• cheaper than BaKoMa (†)
• supports LuaLaTeX

(*): My attempts to use precompiled preamble (which is basically user-written format file) in LuaLaTeX has all failed, partially because Lua states and some other things cannot be dumped. maybe I should just switch back to pdflatex for the speed, especially now I am better at forcing TeX to do what I want (†): There's now WYSIWYG editing though. (unfortunately)

The basic idea is to use fork() to spawn new process when part of the file change, instead of re-run it from scratch.

Proof of concept code:

%! TEX program = lualatex
\documentclass[12pt]{article}
\usepackage[paperheight=5cm,paperwidth=5cm,margin=0.6cm]{geometry}
\usepackage{luacode}
\begin{document}

% you can write some LaTeX here too

\begin{luacode*}

-- load the package
package.path = "/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/lib/lua/5.3/?.lua;/usr/lib/lua/5.3/?/init.lua;./?.lua;./?/init.lua"
local posix=require "posix"

function copyfile(source, target)
local infile=io.open(source, "rb")
local outfile=io.open(target, "wb")
infile:close()
outfile:close()
end

--first backup the partial PDF content
copyfile(tex.jobname..".pdf", "backup-"..tex.jobname..".pdf")
copyfile(tex.jobname..".log", "backup-"..tex.jobname..".log") -- strictly speaking this is not necessary

while true do
local pid = posix.fork()
if pid == 0 then
-- is child, compile b.tex
break
else
-- is parent
posix.wait(pid)
print("======== Press enter to recompile ========")
-- **critical**: restore the partial PDF content
copyfile("backup-"..tex.jobname..".pdf", tex.jobname..".pdf")
copyfile("backup-"..tex.jobname..".log", tex.jobname..".log")
end
end

\end{luacode*}

\input{b.tex}

\end{document}


First create a file named b.tex, put in some content.

Then run lualatex a.tex where a.tex is the main file (above).

When you edit b.tex, press enter in the lualatex process. It will regenerate a.pdf instantaneously... as long as b.tex isn't too long.

• Actually this solution is quite buggy and more likely to fail than not. Apr 2, 2022 at 7:47
• Actually no-backup (other than hard-link to preserve the (busy) file) seems to be sufficient for pdf and synctex. But aux is the odd one, it doesn't seek. Apr 2, 2022 at 8:45
• Another thing (unrelated to this answer however), \usepackage speed is improved in newer expl3 version, so upgrading might make it faster, see chat.stackexchange.com/transcript/message/60905323#60905323 for some discussion. Apr 16, 2022 at 10:37