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.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While I was discussing another issue I came across this problem:

I included the xfrac package and the compile time of my document 100folded. After playing around I found out that microtype caused the problem. Assume the following document:

Divide $4$ by $2$: $\sfrac{4}{2}=\sfrac{40}{20}\neq
\sfrac{42}{22}\neq\sfrac{2}{3}=\sfrac{4}{6}$. If you use many
$\sfrac{1}{2}$, $\sfrac{7}{8}$ and
microtype together it will take loooong to compile.

If you insert more copies of the text you'll encounter longer compile times. I inserted 16 copies and the document compiled ~20 seconds. When I remove the microtype package it will compile in under one second.

Can anybody explain why it takes that long? Is it maybe a bug in microtype?

share|improve this question
Are you using microtype from CTAN (2.4)? This version has some performance issues that are fixed in the 2.5 beta from tlcontrib. – Robert Sep 9 '11 at 19:29
Wow, I'm impressed. I tested it with Mico's example. His document compiles in ~2 seconds with 2.5 and in ~29 seconds with 2.4. It seems that this update solved the problem. – qbi Sep 9 '11 at 21:27
@Robert: As per meta.tex.stackexchange.com/questions/1731/…, could you convert your comment to an answer. – Joseph Wright Sep 10 '11 at 10:40
As a note, \nicefrac causes similar slowdown in my tests, though I didn't use this MWE but a document I'm working on. – Canageek Apr 18 '12 at 19:19
up vote 16 down vote accepted

(First a suspicion, now the answer, as per Joseph's request:)

The performance issues you encounter with microtype version 2.4 are fixed in v2.5 available from tlcontrib.

share|improve this answer
Any idea when this will be up on CTAN? – Canageek Apr 18 '12 at 19:19

Packages that use a lot of calculations and loops can cause execution to be slowed down. Microtype does a lot of calculations and iterations to optimize spacing between letters, words and determining optimum lines. I would guess in O(n3) time.

See my answer at Benchmarking various operations of TeX

xfrac and anything using LaTeX3 in general runs slower. If you are after speed use TeX straight.

share|improve this answer
I'm not after speed in general, but it matters if my document builds in 13 seconds or nearly half an hour. However it seems the best workaround to disable microtype until finalizing the document. – qbi Sep 9 '11 at 15:16

I've replicated your MWE with 20 copies over the sample text. Importantly, if you replace all \sfrac commands with "ordinary" \frac commands, the difference in compile times between the programs with and without microtype feels negligible. This suggests that it's not some inherent deficiency (or, if you will, programming bug) in the microtype package that's causing the big slowdown but, rather, some kind of extra spacing/stretchability features built into the \sfrac macro that is forcing microtype to work extra hard.

By the way, with 20 copies of the sample text you provide, the outputs of the program with and without microtype are definitely not identical. Specifically, whereas both pdf files consist of one long paragraph of 24 lines, only lines 1-6 and 18-24 of these paragraphs are identical. The 11 lines in between these blocks, i.e., lines 7-17, are at first set more loosely in the version with microtype enabled than in the "plain" version (without microtype), but by the end of line 17 the microtype version has fully caught up with the plain version (thus causing lines 18-24 to be the same again). Eyeballing the two pdf files side-by-side does not show much of a visual difference at first glance. However, on further inspection I notice that the microtype version succeeds, in lines 14-17, in displaying the longer math sequence somewhat more harmoniously (i.e., more even interword spacing). Not a huge difference, for sure, but it may be important for sticklers...

Finally, in case someone wants to experiment with what I've reported, here's my version of the MWE:

\newcommand{\textblock}{Divide $4$ by $2$: $\sfrac{4}{2} = 
  \sfrac{40}{20} \neq \sfrac{42}{22} \neq\sfrac{2}{3}= \sfrac{4}{6}$. 
  If you use many $\sfrac{1}{2}$, $\sfrac{7}{8}$ and
  microtype together it will take loooong to compile. }
%% 20 repetitions of the text contained in "textblock"
\textblock \textblock \textblock \textblock \textblock
\textblock \textblock \textblock \textblock \textblock
\textblock \textblock \textblock \textblock \textblock
\textblock \textblock \textblock \textblock \textblock
share|improve this answer
Thanks for analyzing the problem, IMHO it is LaTeX3. There were similar issues in the test I referred with SIunits. – Yiannis Lazarides Sep 9 '11 at 15:54
You're welcome, Yiannis. I guess the big question, going forward, has to be: what exactly in LaTeX3 causes microtype to work so hard? In my answer, I've noted that the presence of the \sfrac (rather than just \frac) macros was the immediate cause of the slowdown. But, is this problem specific to the \sfrac macro, or does it arise because the \sfrac macro relies on some LaTeX3 capabilities that could stand (a lot of) further optimizing? I guess time will tell... – Mico Sep 9 '11 at 16:02
See Roberts comment above. He suggested using v2.5 and it brought a huge improvement. – qbi Sep 9 '11 at 21:27

Your Answer


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.