33

The most obvious way to speed up LaTeX processing is to split a large and complex document into smaller pieces. For example, Makefiles, \beginpgfgraphicnamed/\endpgfgraphicnamed when using TiKZ, and splitting a large file into separate chapters are all helpful in splitting a large job into smaller, hopefully independent pieces. But sometimes this is not enough -- many packages do complicated things under the hood, leading to slow document processing.

Are there any tools to help isolate the culprits?

It would be great to also have the profiling tool provide suggestions on ways to speed things up.

Charles Stewart
  • 21,014
  • 5
  • 65
  • 121
András Salamon
  • 2,145
  • 3
  • 25
  • 33

3 Answers3

21

pdfTeX (which is the default nowadays, even if you're generating DVI) has functions for doing timing tests. Use \pdfresettime to start it off and do ‘something’ with \pdfelapsedtime when you're done:

\documentclass{article}
\pdfresettimer
\usepackage{expl3,tikz}
\showthe\pdfelapsedtime
\begin{document}
\end{document}

The value of \pdfelapsedtime is the number of seconds elapsed multiplied by 65536.

15

Perhaps not quite what you're after, but the trace package is used by the LaTeX Project to get a feel for the 'cost' of different things. This package lets you include every TeX expansion and assignment in the log file. So you can check how many lines a particular function adds to the log, which gives you an idea of how hard TeX is working to do whatever you've asked for. Other than that, the approach I take is to create simple test files (say one with a loop to repeat one function many times), then use 'time' at the command line to see what changes as I alter the input.

Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
10

tikz/pgf seems to provide a general profiler built on top of \pdfelapsedtime to optimise TeX code. See "44 Profiler Library" in its manual from a recent CVS checkout. The stable release pgf 2.0 is out of date.

Dave Jarvis
  • 11,809
Leo Liu
  • 5,445
  • For anyone still wondering in '21, this should probably be the accepted answer, as pgf/TikZ provide a profiler library which does exactly what OP asked. Profiling of individual commands and environments has to be declared manually but the output is provided in the log and in a special output file. This allows you to profile à la MATLAB. – Jonas Zaugg Aug 17 '21 at 09:25
  • https://mirror.kumi.systems/ctan/graphics/pgf/base/doc/pgfmanual.pdf (currently 67 Profiler Library) – janniks Sep 17 '21 at 15:19