24

I've been using Latex for several years, but recently I've found that I can get crazily varying compilation times.

For example: I am currently working on a ~15 page document with around 10 high quality eps/pdf figures and a bibtex bibliography. I find that for several days it will compile everything in ~30s. I then replace one word in the main body text, and compilation takes over an hour, with no new messages in the log. After another few days working on it, it goes back to 30s. This has happened previously as well with much smaller documents.

Clearing out auxiliary files has no effect on this: if it was compiling quickly it keeps compiling quickly; slowly then still slowly.

For reference I'm using pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013) on Mac OSX 10.9.2. I've not included any sample code as this happens with such a huge range of documents and style files: I haven't been able to find a single culprit.

Has anyone seen or heard of anything like this before? I haven't been able to find anything online.

Edit: Thanks to @Heiko I've tracked the issue down to the float placement. However, I still don't know why this is such an issue. In particular, if I try to compile the document on a computer running Linux, the same document compiles in about 2s every time. So why are the floats causing such a problem on Max OSX?

3
  • 1
    Welcome to TeX.SE. I have had some issues related to the microtype package: Disable microtype for a portion of a document. If you are using that, try taking that out and see if the compile time is improved. Apr 10, 2014 at 13:51
  • Suggestions: even without an MWE, a list of packages might be of interest; any network locations involved?; if you watch CPU usage does it (1 core probably) sit at 100% for the whole compile?
    – Chris H
    Apr 10, 2014 at 14:02
  • For THIS case packages are: amsmath natbib hyperref placeins and using documentclass emulateapj (which I believe calls some itself). The time issue stays even if i remove all of these though (haven't tried removing emulateapj though; but problem was there before i switched from article to emulateapj). And yes: it looks like I have one core sitting at 95%. No network locations.
    – RTunnard
    Apr 10, 2014 at 14:15

1 Answer 1

34

There are some ways to debug the problem. First the part of the code causes the long delay should be identified.

  • Markers can be put into the log (short for console and/or .log file), example below. This should help to identify the parts that are compiled in a reasonable time and which are not.

  • There are many \tracing... commands that can be activated. For example, TeX writes its macro expansions into the log, if \tracingmacros=1 is set. I recommend to limit the scope of such tracing commands as closely to the problematic code as possible. Otherwise the .log file can become very huge very fast.

  • The techniques for generating a minimal working example (MWE) are also very helpful, because it reduces the code for a deeper analysis.

Example for time markers using pdfTeX's \pdfelapsedtime:

% \marker[annotation text]
\makeatletter
\newcommand*{\marker}[1][]{%
  \begingroup
    \edef\x{\the\pdfelapsedtime}%
    \count@\x\relax
    \divide\count@\p@
    \edef\s{\the\count@}%
    \count@\s\relax
    \divide\count@ 60 %
    \edef\m{\the\count@}%
    \count@\m\relax
    \divide\count@ 60 %
    \edef\h{\the\count@}%
    \edef\s{\the\numexpr\x-65536*60*\m}%
    \dimen@\s sp %
    \edef\s{\ifdim\dimen@<10pt 0\fi\strip@pt\dimen@}%
    \edef\m{\the\numexpr\m-60*\h}%
    \edef\m{\ifnum\m<10 0\fi\m}%
    \edef\timestamp{\h:\m:\s}%
    \immediate\write16{%
      [\timestamp] #1%
    }%
  \endgroup
}
\makeatother

\marker[before document]
\documentclass{article}
\marker[after document]
\usepackage{tikz}
\marker[before begin document]
\begin{document}
\marker[after begin document]
\section{Hello World}
\marker[before end document]
\end{document}

Example output:

[0:00:00.02332] before document
[0:00:00.02853] after document
[0:00:00.1714] before begin document
[0:00:00.1877] after begin document
[0:00:00.18898] before end document
6
  • As it's intermittent the timestamps look like a low-overhead good place to start.
    – Chris H
    Apr 10, 2014 at 14:00
  • Thank you: I'll try and use the time markers to find the bug. Although looking at it now (currently trying to compile), it seems to be the placement of a single float that is causing the delay. I've tried changing the size of the float (on the page as well as reducing the image size) and that didn't change anything.
    – RTunnard
    Apr 10, 2014 at 14:09
  • Oh sorry: I didn't know about markers before this so didn't realise! I'll try with \pdfelapsedtime instead :)
    – RTunnard
    Apr 10, 2014 at 14:17
  • @egreg: Yes, I have updated the answer with \pdfelapsedtime including a formatted time stamp. Apr 10, 2014 at 14:35
  • 4
    @HeikoOberdiek Having had a play commenting out various figures, it seems to just be a float placement issue: no one figure by itself is causing the problem, but with all of them there Latex starts to find it incredibly hard to find a way to place them all...
    – RTunnard
    Apr 10, 2014 at 15:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .