Which constructs would cause a long compile time in a Document?

I have a friend which writes a rather long document. By now he has about 130 (PDF) Pages. He uses TexWorks on Windows and his document takes sometimes up to 2 - 3 minutes until it is compiled.

I'm not asking if this time is normal for such a long file. I know it depends on many things and every PC would have different times depending on the CPU etc.

But I was wondering which constructs in a tex file would take especially long time if there are many of them in a document.

For example I could imagine that including many images would take a lot of time since every external file has to be loaded into the document (assumed draft is not enabled).

Also in his document he very often uses mbox to prevent hyphenation. If given a lot of those, would that increase the time the document takes to compile?

As an last example: he didn't know the option openright and thus used \newpage everywhere where he wanted a new chapter to open on the right page. Does this cause extra compile time?

I hope my question is clear enough.

Edit: One more thing I saw in his document. As the very first line I saw \documentclass[all]{...}. I didn't know that the option all existed. Does it do what I imagine? Does it actualy enable every possible option? But isn't that contradictory? For example for parskip and halfparskip? Would this hurt the performance? I imagine it to be like in Java import *.

• PNG images can slow down compilation. – egreg Oct 2 '14 at 11:16
• I've found that a slow computer contributes significantly to long compilation times ;^) (I'm only half joking. Sometimes, upgrading a computer is the proper course of action) – Steven B. Segletes Oct 2 '14 at 11:17
• Complicated commands that do a lot of behind the scenes stuff will slow down the compilation. For example, sorting data with datatool or similarly using TeX to internally sort the glossaries with the glossaries package (rather than using makeindex or xindy to do the sorting) or complicated picture-drawing code, such as tikz. Regarding all, that's either specific to the particular document class being used or it gets picked up by one of the loaded packages. – Nicola Talbot Oct 2 '14 at 11:44
• Comparing the compilation time from TeXWorks and from the command line may give a good suggestion, what slows down the process. – Przemysław Scherwentke Oct 2 '14 at 12:03
• There are not enough power computer for the user that do not think "make it simple, idiot" until he obtain a snail compilation time. The severity of the problem is often proportional to the kilometers of the preamble. – Fran Oct 2 '14 at 23:41

But TeX is a typesetting engine, and while it's Turing-complete, things that require a lot of processing aren't going to be particularly efficient when we ask TeX to do them. The example that springs most immediately to mind (due to its recent release) is the qrcode package, which uses TeX to convert strings of text into binary data and then builds graphical QR codes from them. TeX is capable of this sort of thing, but wasn't designed for it; so it takes a bit longer to process a QR code than it does simple text. (Not much longer in this case; qrcode appears to be quite excellent. But still.)
As also mentioned in the comments, extensive drawing in TeX will likewise take more time. tikz and friends suffer from this; though again, the efficiency of these programs is remarkable given how far they're stretching TeX beyond its original bounds. shapepar, though it's using TeX for its intended purpose, coerces TeX into typesetting paragraphs in odd and creative shapes, and has to run repeated tests to determine how best to fit given texts into those shapes; as a result, it often takes longer to run than simply typesetting text in normal, rectangular paragraphs would.