Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

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}
...
share|improve this question
1  
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
4  
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
add comment

6 Answers

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.

share|improve this answer
1  
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 at 17:06
add comment

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!

share|improve this answer
3  
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
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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