Speed up beamer compile time

Question

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}
...

Answer 1

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.

MWE:

\documentclass{beamer}
\includeonlyframes{current}
\begin{document}

\begin{frame}[label=current]
    This frame will be included. 
\end{frame}

\begin{frame}
    This frame will NOT be included. 
\end{frame}

\end{document}

Answer 2

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}
Your presentation here…
\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!

Answer 3

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.

Answer 4

@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
   beamerbasenavigation.sty        26 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.

Answer 5

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.

Answer 6

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

Answer 7

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.

See also: Is there a nice way to compile a beamer presentation without the pauses?

Answer 8

I agree with @Ottorino, it is a good solution to use the capabilities of the editor to quickly compile the current frame. For vim, see this answer https://stackoverflow.com/a/7474218/1342186. By defining a function like:

function! CompileCurrentSlide()
   let tmpfile = "current-slide.tex"
   silent! exe '1,/\s*\\begin{document}/w! '.tmpfile
   silent! exe '.+1?\\begin{frame}?,.-1/\\end{frame}/w! >> '.tmpfile
   silent! exe '/\s*\\end{document}/w! >> '.tmpfile
   exe '!latexmk -shell-escape -pdf '.tmpfile 
endfunction

and using a map like:

noremap <silent><buffer> \ff :silent call CompileCurrentSlide()<CR> 

You can compile only the current frame by pressing \ff with the cursor inside the frame environment.

You can add a visualization macro too, for instance using mupdf and pressing \fv:

noremap \fv :execute "silent !mupdf current-slide.pdf 2>/dev/null &"<CR>:!redraw<CR><CR>