TikZ is dangerous. When you realise that it's far too slow, you have already invested a lot of time creating the illustrations, and it's too late to change the tools. Of course this doesn't help you now, but I'd suggest that it's best to avoid TikZ in future. (External compilation helps, but with it you also lose some of the best features of TikZ - tight integration with your Latex source code. When I got really desperate with a particular TikZ-heavy document, I did editing & compilation over an ssh connection on a very fast Unix server.)
–
Jukka SuomelaJul 26 '10 at 20:15

9

@Jukka: but isn’t tight integration really rare? And for all other cases, externalized graphics work really well. All in all, I’d say that you’re overly pessimistic, except if your document uses very complex overlays that interact heavily with the rest of the document.
–
Konrad RudolphJul 26 '10 at 20:21

1

@Konrad: Of course you are right, people have different needs. But the tight integration (single source file, single-step compilation, simple way to re-use the same set of macros in pictures and text, possibility to use loops and macros to generate a bunch of related illustrations and captions easily, etc.) was one of the main reasons why I initially got excited about TikZ, together with its PDF support. However, I think that if you don't need the tight integration, then there are plenty of other options available as well (e.g., Xfig + a bunch of scripts; R).
–
Jukka SuomelaJul 26 '10 at 20:43

6

Is this question a general question on performance, or is it a specific question about performance when using TiKZ?
–
András SalamonJul 26 '10 at 22:20

You can try creating a Precompiled Preamble or "format" for your document. This technique basically caches all the computations that LaTeX does when processing the preamble which is the stuff before \begin{document}. If your packages, macro definitions, etc are not changing it can produce a noticeable savings in time.

Update

Just noticed the reference to TikZ- in this case Scott's suggestion is the most pertinent.

Make is Your Friend!

This problem was solved ages ago, so let's take advantage of all the nice tools Unix gave us!

The best solution I can think of for a large document is to simply not have any \begin{tikzpicture} or \tikz macros in it and do everything with \includepdf.

To this end, I made a makefile (for GNU Make) that looks (and I do mean looks. Makefiles are old technology - so old that tabs are actually significant syntax...) sort of like this for a project of mine (ignore the syntax highlighting. tex.SE thinks this is TeX and it's obviously not):

How do I use that?!

Whenever you'd use a tikzpicture environment or a \tikz macro, give your picture a suggestive name, say riemann_sum, put the TikZ code in a single standalone document (with some boilerplate such that it matches the style of your main document. For example we don't want Computer Modern in our pictures while the main document is typeset with Times or a 10pt/12pt font size clash) called riemann_sum_sag.tex and use \includepdf{riemann_sum_sag} instead. The goal is to not have a single picture being compiled when you run make without having modified a *_sag.tex file. If this is not possible because you need to \ref something inside a picture, then so be it, but try to keep that to a minimum and instead choose good captions or something.

You'll also notice that there is a rule for files matching *_input.tex. This is for splitting the project into multiple files which is of course always a good idea when doing large projects. The rule detects whether such a file has been modified, and if it has triggers a recompilation of the document. LaTeX's \includeonly feature might be a good companion to this.

Another way to speed-up compilation is to figure out what it is that is making each picture slow and then do something about it. As a case study, it just took nearly 18s to compile the source for this seminar. That's a bit long for a compulsive recompiler like me! Watching the page numbers go by, I could see that the picture that takes the longest is on page 51. The source of this diagram is available and it's fairly clear that it's the torus that takes the time (there are two foreach loops, nested). If you look carefully at the start of the foreach loops, you'll see:

Even without looking at how the various commands are defined, it's clear that by changing them, I can change how many times these loops loop. Thus when I'm working on the diagram itself then I can use values that I'll use in the final document, but when I'm working elsewhere in the document, I can set them to something a little more user-friendly. Indeed, near the top of the document, I have:

which sets a global option (of course, I can override it for a particular picture when I'm actually working on it). (Note: \ifdraft isn't a standard "if", hopefully it's obvious what it does.)

One more tip: when working on a document with lots of diagrams, I often have a "diagram-only" file for working on a specific diagram at a time. This has the same preamble as my main document but only one diagram in it (the one I'm currently working on). It's like a scrap piece of paper. To save my working, when starting to a new picture then I just put a \end{document} in above the previous picture.

I use plain XeTeX†, so the externalization described in the TikZ manual doesn't work for me. But I've found a neat way to speed up my compilations.

Like Andrew shows in his answer, I split the figures to their own .tex file, so that I have maindocument.tex and maindocument-figs.tex. Inside maindocument-figs.tex, I make sure the fonts, baselineskips, etc. are the same between the two TeX files. Then I use a simple macro inside the -figs.tex file:

If it's your TikZ graphics that are taking a long time, use the standalone package to have them in a separate file.

As for more general hints, if you are compiling a big document, but you only really need part of it to compile (e.g. if you're compiling a book, but only chapter 3 has changed) split the file into several files and use \include to put it all together. Then you can use \includeonly{chapter3} for example, and only chapter 3 will be compiled. This is useful for compulsive recompiliers like me...

Ah, I just found this question and naturally wanted to add standalone. Thanks for mentioning it. The upcoming version will include some feature which allows to compile included standalone pictures from the main file and include the resulting PDF in the next runs. This heavily decreases the compile to while only slightly increases the file size. There will also be the possibililty to automatically recompile the standalone pictures when the TeX file is newer than the PDF.
–
Martin Scharrer♦Apr 4 '11 at 18:34

I don't use TikZ, so I've no idea if this will help with TikZ-related slowness. But, the question asks how to speed up compilation (in general).

Using the draft option in your \documentclass declaration will cause many different packages to skip some steps or niceties and will thus give a speed boost. When compiling the final document, either remove the draft or replace it with final.

This inserts the text "Picture" instead of any tikzpicture environment. The advantage of this method is that this is all you need to change, whereas the "externalization" or "standalone" solutions require (minor) modifications in other places, be it the build procedures or the files that contain TikZ code.