# Speed up beamer compile time

Is there a way to speed up the compile time? I have a, I would say, medium-sized presentation and it takes 10+ seconds to compile. It isn't too much, but it's annoying. Especially since I'm performing minor local changes between the compilations. Is there a way to tell beamer to compile only the parts that changed?

My manual solution is to take parts of the presentation out to a different file, comment out the \include and put it back in at the end. I.e.:

...
\begin{document}
%\include{Section-1-done}
%\include{Section-2-done}
\include{Section-3-in-progress}
...

-
Do you have a lot of vector graphics like TikZ or PSTricks in the document? If so, turning them into PDF or EPS graphics would speed up the process. –  Martin Scharrer Sep 3 '11 at 16:43
All my graphics are PDFs –  Guy Sep 3 '11 at 17:01
There are some answers to how can i speed up latex compilation, one of the first questions asked on this site. A major issue in that case did relate to tikz diagrams but the answers also provide other useful suggestions. –  mas Sep 3 '11 at 18:37

Section 4.3.3 of the beamer user guide (texdoc beamer on a Unix system) is called "Ways of Improving Compilation Speed". There are two suggestions there: to use the draft class option, and to use the \includeonlyframes{list,of,frames,to,process} command. This means that only frames whose label matches one in the list will get processes. The suggestion is to have \includeonlyframes{current} and to keep moving the current label from frame to frame as you work on different ones.

-
draft speeds things up a bit. (From ~13sec to ~7sec). However you don't get the images which I find annoying. I'll see if I can get used to working with current - thanks! –  Guy Sep 3 '11 at 17:16
just to be complete: texdoc beamer works also on non-Unix systems (like Windows) if you installed TeXLive –  Spike Sep 10 '11 at 19:44
\includeonlyframes option does not work with Lyx frames. I have posted a separate question. tex.stackexchange.com/questions/140388/… –  dips Oct 24 '13 at 13:03
@dips: This is a problem with LyX, not beamer. LyX completely redefines the way frames are created... –  Werner Oct 25 '13 at 22:08
When I put the \includeonlyframes{current}, then it shows file not found. What I do ? –  Deepesh Patel Mar 6 '14 at 17:06

In his answer Werner mentions that just loading beamer takes a lot of time. The problem is that all the definitions have to be processed anew on each TeX run. Because this problem is common and especially significant for large macro collections like LaTeX itself, TeX has a mechanism to deal with it.

TeX defines a notion of a format or a format file, which is a compact dump of TeX's internal state at some point of processing TeX's input. A format can be input by TeX significantly faster than the macro collection it was generated from, because TeX does not have to process the input again. This is somewhat analogous to interpreted and compiled programs: interpreted programs' source has to be parsed each time the program is run, while compiled programs can be loaded and executed directly.

Formats are denoted using the &fmtname syntax. For example, the LaTeX format is named &latex. When you compile a LaTeX document, the first thing that actually gets loaded is the format itself. You can load it explicitly by specifying it on TeX's command line:

tex "&latex" latex-test.tex

Formats differ per engine, so there are actually also &pdflatex, &xelatex, &lualatex etc. formats.

Now let's get back to beamer. It is possible to create a format that contains both the LaTeX's definitions and beamer's definitions on top of them. We will use the mylatexformat package for that (be sure to read its documentation for more info!).

Create a file mybeamer.tex with the following contents:

\documentclass{beamer}
\begin{document}
\end{document}


You can also extend the preamble with packages and/or code you frequently use.

Then execute this command (change the names if using XeTeX or LuaTeX):

pdftex -ini -jobname="mybeamer" "&pdflatex" mylatexformat.ltx mybeamer.tex

A file mybeamer.fmt is created, which is our new format. To load the format, either use the command line syntax mentioned above or specify it in the source file:

%&mybeamer

\begin{document}
\end{document}


Tests on my computer show that mybeamer.tex takes about 340 ms to process with pdfTeX, while the document using the new format takes only 109 ms. That's roughly three times faster!

-
Nicely written. I often though why specifically pgf and beamer don't have their format file. About your speedup -- you cut down on the constant part, so odds are that it will be faster by 130ms even for large jobs, i.e. un noticeable. –  eudoxos Nov 11 '11 at 20:54

@Andrew's solution is a beamer-provided solution, compared to your LaTeX-provided solution, and is probably what you're looking for. Consider this "answer" an elaboration on why the compile time may be longer-than-usual, regardless of what you do:

1. The beamer document class virtually redefines all the standard LaTeX commands and environments to accommodate its easy-to-use "overlay specification". In large part, I would attribute the 10+ seconds to beamer loading all of it's base modification. In particular, here is the current base libraries/files included with beamer (as of June 17, 2010 on CTAN), most of which are loaded by just using \documentclass{beamer}:

beamer.cls                      11 KiB
beamerarticle.sty                1 KiB
beamerbasearticle.sty            3 KiB
beamerbaseauxtemplates.sty      21 KiB
beamerbaseboxes.sty              8 KiB
beamerbasecolor.sty             12 KiB
beamerbasecompatibility.sty     23 KiB
beamerbasedecode.sty             8 KiB
beamerbaseexercise.sty           1 KiB
beamerbasefont.sty              12 KiB
beamerbaseframe.sty             24 KiB
beamerbaseframecomponents.sty   11 KiB
beamerbaseframesize.sty          8 KiB
beamerbaselocalstructure.sty    14 KiB
beamerbasemisc.sty               8 KiB
beamerbasemodes.sty              8 KiB
beamerbasenotes.sty              5 KiB
beamerbaseoptions.sty            2 KiB
beamerbaseoverlay.sty           25 KiB
beamerbasercs.sty                1 KiB
beamerbaserequires.sty           2 KiB
beamerbasesection.sty           12 KiB
beamerbasetemplates.sty          6 KiB
beamerbasethemes.sty             1 KiB
beamerbasetheorems.sty           5 KiB
beamerbasetitle.sty              5 KiB
beamerbasetoc.sty                7 KiB
beamerbasetranslator.sty         1 KiB
beamerbasetwoscreens.sty         1 KiB
beamerbaseverbatim.sty           3 KiB


In addition to this 275 KiB list of style files, some other external packages are loaded as well (including geometry, graphicx, xcolor, to name just a few). Consider viewing the <jobname>.log file after compiling the following minimal working example:

\listfiles
\documentclass{beamer}% http://ctan.org/pkg/beamer
\begin{document}
Hello world.
\end{document}


In fact, you will find that LaTeX parses through at least 100 style, configuration and other related class files in typesetting this MWE. This will at least give you a baseline according to which you can compare your minimum compile time.

2. beamer builds on pgf's basic layer, and therefore allows embedded pictures via (say) the tikzpicture environment. Embedding detailed graphics or diagrams in your code (rather than importing already-processed PDF graphics) adds some of the strain on LaTeX's compiler during processing, rather than viewer (Adobe Reader, say). You may notice a slight difference in compile time by include already-processed/stand-alone images using \includegraphics rather than tikzpicture.

3. This is a fundamental feature of LaTeX. Minor editing changes may result in major typesetting changes. Take, for example, re-jigging an overlay specification, which results in a switch of slides for a specific frame. Labels and their associated references (including a table of contents) are notorious for this, requiring at least 2 compilations, if not 3 in some (possibly worst) cases. However, this is still a feature, since LaTeX takes care of everything - both the referencing and typesetting.

4. Using a LaTeX IDE invariably adds some overhead to the compile time. This may be sped up marginally by compiling your document from the command line: pdflatex <jobname>. However, switching between a syntax-highlight GUI, command line and PDF reader may void any advantages gained in compilation reduction, making this point slightly moot.

-

Andrew's "moving label" approach works best if you want to restrict compilation to a single frame only, but can become pretty inconvenient if you work on more than one frame (e.g., a complete (sub-)section of a larger lecture) or employ frame labels for different purposes (cross-referencing, \againframe) as well.

Another (a bit less intrusive) option is to employ the comment package. This package basically provides you a comment environment that makes LaTeX to ignore everything between \begin{comment} and \end{comment} lines. So I usually end up with a \begin{comment} after the title slide and a moving \end{comment} line; in rare situations (working in the middle of a really large lecture) I need two comment environments.

-

As this is proving a popular question, I'd like to add one other piece of advice that I suspect might not be relevant directly to the original questioner (based on how the question was phrased) but which might be useful for others looking at this question.

I keep my lecture presentations as a single file. It makes it easier to maintain consistency of style across the lectures and to cut-and-paste bits from one lecture to another. But the order of 30 lectures can be a large file (c. 400Kb). Using the \lecture command doesn't actually help because the other lectures still get processed, they just don't get typeset.

Each lecture starts with:

\mode
<all>
\lecture{Lecture title}{date}


Then I have (in a style file) the commands:

\g@addbefore@macro\beamer@atbeginlecture{
\lecturemode
}


where \lecturemode is defined as:

\newcommand{\lecturemode}{%
\ifbeamer@inlecture
\else
\expandafter\mode\expandafter<\expandafter n\expandafter o\expandafter n\expandafter e\expandafter >\fi
}


(This could be a bit neater; I wrote this before I'd started hanging around here.)

The point is that if we're not in the current lecture (as specified by \ifbeamer@inlecture) then we go in to "gobbling". We carry on gobbling until we get to the start of the next lecture where the \mode<all> turns back normal operations. We read the next lecture name, test to see if it's the lecture we're supposed to be typesetting, and if not we resume gobbling. This ensures that we skip all unnecessary lectures completely, whilst keeping the count of the number of lectures correct.

This isn't of use to a single presentation, which I infer from the question is the questioner's particular circumstances, but may be of use to others who are also looking to speed up beamer and who are using it for multiple lectures in a single file.

-

Using Beamer's handout mode also increased the compilation speed in my case:

\documentclass[handout]{beamer}


It's also more comfortable to work with since you don't see each and every pause (\only, \onslide) you created.

-

Providing you are using emacs/xemacs, you can compile only a frame. I've found this only recently and is going to be my favorite trick with beamer

http://lists.gnu.org/archive/html/auctex/2006-01/msg00023.html

-