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?
  • 7
    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
  • 3
  • 5
    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
  • 3
    @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

17 Answers 17


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.

  • 5
    +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
  • 12
    @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
  • 1
    @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
  • 5
    @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
  • 1
    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.

  • 7
    Couldn't the second pdflatex run also use -draftmode? – Philipp Jan 12 '11 at 12:47
  • 1
    @Philipp: yes, we can ... :-) – user2478 Jan 12 '11 at 13:07
  • 1
    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
  • 2
    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
  • 6
    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.


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.

  • 1
    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. – enthu Jan 13 '20 at 9:36

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.

  • 2
    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
  • 2
    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
  • 4
    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

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.

  • 5
    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
  • 3
    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
  • 1
    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:


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


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:

   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.

  • 5
    If you don't generate a PDF how do you preview the layout? – lhf Oct 3 '12 at 2:27
  • 2
    Normally you use -draftmode in the first two of the three runs before the last—that's why you use it "for the first runs (except the last)", as the post says. – Blaisorblade Mar 18 '17 at 16:25

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


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.


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.

%\renewcommand\accentedsymbol[2]{\def#1{#2}}  % Uncomment for final version

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


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


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?

  • 20
    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
  1. For a large document, I would suggest making seperate tex files and using \include{filename} to include these files into the main file. Then, in the preamble, you can add command \includeonly{filename1} to start working on the file. There has been a quick fix around to comment out the code at \include to temporarily remove the files you are not using, but it disturbs the aux files. So, it's not recommended.
  2. Do not use todonotes package. It seems that i am not the only one who has an slowing down issue with this package.
  3. Use draftmode. It specially helps when you have a lot of images and it can be declared in the very beginning. I choose to keep the declaration code in individual lines so it's simpler to just comment/uncomment the lines to switch draftmode on/off.
  1. Don't compile every now and then. It's probably not applicable to you or many others here, but people recently migrating from WYSIWYG softwares like MS word are more used to seeing a compiled document everytime. It helps to get used to read the TEX code for how it is.

It is not about "speeding up" but "how to work when latex is really slow".

I use kile+okular.

  1. In the setting of okular uncheck "reload document on file change".
  2. Add "reload button" to the toolbar of okular

After that you can continue to read pdf file, and reload it only when it is ready.


Depending on your file system, file read/write times might be slowing *latex down. If you are on a Unix like system, you could keep all your resources in RAM. To do so you would first mount a ramdisk:

mkdir /mnt/ramdisk;
sudo mount -t tmpfs -o size=64M tmpfs /mnt/ramdisk;

(be sure to pick a sufficiently large size so your entire project including all resources will fit)

Than every time you want to rebuild, you would run:

rsync --archive --human-readable --progress --update --exclude=\"thesis.pdf\" . /mnt/ramdisk; 
cd /mnt/ramdisk; 
pdflatex thesis.tex; 
cd /path/to/your/thesis;

This syncs all changes you may have made since the last run (using rsync) and than invokes *latex on that copy of your files. The output is found in /mnt/ramdisk/thesis.pdf. I will simply open this in my viewer but at least in some circumstances one might like to sacrifice some time and copy the result to the original location (cp /mnt/ramdisk/thesis.pdf thesis.pdf).

This worked really well for me, as I used this setup to bring down compile times from 45 to 3 seconds.

  • How can I find the size required? Can I take size of complete folder with all tex files and images? – kaba Jan 1 '20 at 18:02
  • Yes, take the size of all images, tex files and the pdf output and add a view MB just to be on the save side. If your value is to low (latex should give you an error like "cannot read/write file" if that is the case) you can always increase it (maybe using mount -o remount ...). Just don't be too generous. You can use free to check how much RAM is available and you don't want to use significant parts of your RAM unless you really know what you are doing. On my 8GB RAM laptop I wouldn't want to use more than 1GB or 2GB. – JakeI Jan 1 '20 at 22:17
  • Thanks for explanation! – kaba Jan 2 '20 at 10:49

So, What I did to handle the costly compilation is that, I first split up the document into the several chapters and every chapter into its own file, using the \input command. The main document has all the \input statements.
Inside the main_file.tex


Only the ones that are critical are not commented out. 'chapter1_results.tex' takes a lot of time to compile because of presence of figures. So I do the following, and its fast as hell.

Inside the main_file.tex

  • 2
    This is very similar to Leo Liu's answer. – Werner Jul 18 '16 at 19:41
  • 5
    Why don't you use \includeonly as described in Leo Liu's answer? – PTNobel Jul 18 '16 at 20:05
  • You are absolutely right! thanks for pointing out. I didnt know there was an \include command unitl now... I looked for \input, but didnt find it... Read the first two answers and glanced over the other comments. I should delete it right? \include makes the whole file a separate logical unit, where as \input just copy&pastes the content. I still find that commenting is easier than typing and removing \includeonly every time you need a file! I guess it might still be useful. – Pandian Le Jul 18 '16 at 21:04

Guess I'm pretty late to the party, but I use something that has not been mentioned here. My documents contain a significant amount of very high quality images, so I make two copies of the image file with one low resolution jpg and one high resolution png. I rename the files such that they have the suffix LOWRES.jpg or HIGHRES.png (I use png because that's what the image making software exports to). And I made a macro in TeXstudio that switches between the two image files.

This is some of my images in my images folder of my tex document:

enter image description here

And in my tex document I would have something like \includegraphics[width=5cm]{methanalLOWRES.jph} And the suffix would be changed by the macro below depending on whether I want to quickly compile a draft or compile to the best quality (which takes a significantly longer time). I use this in conjunction with \includeonly and it has signficantly reduced the compilation time.


scope = editor.document().cursor(0, 0, -1);

if (editor.search("HIGHRES.png", "g") > 0) {

} else {
  if (editor.search("LOWRES.jpg", "g") > 0) {

I added this as a script macro on TeXstudio, so I am unsure if it will work on TeXmaker or other LaTeX editors, but the script is fairly basic and you should be able to implement your own for your own situation.

EDIT: I use this website to resize my images https://bulkresizephotos.com. I simply just make the width 800px, and it outputs a lower resolution jpg file which I download (and unzip if multiple files were submitted). I believe imagemagick can do something similar, but I have not looked into it.

I just saw YuppieNetworking's answer above, which is very similar to my answer, nonetheless I will keep my answer here should someone want to use the script

  • 6
    You could also define a macro: \newcommand{\res}{LOWRES}, so that you could then \includegraphics{methanal\res.jpg}. Then you could switch the macro when you what the high quality version. – Teepeemm Jan 3 '19 at 1:28
  • 2
    ImageMagick: for i in *HIGHRES.png ; do convert -resize 800x $i ${i%HIGHRES.png}LOWRES.png ; done. – sztruks Jan 13 '20 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.