# Why does it take LuaLaTeX so long to load fonts and can I speed it up?

To test Mico's upcoming selnolig package, I tried out LuaLaTeX. While the overall experience for me as a pdfLaTeX end-user was very similar, I noticed that LuaLaTeX takes a long time to load fonts. Here is a sample document that I compiled several times (lualatex foo.tex), measuring the compilation time unscientifically with a clock, deleting the auxiliary files between each compile (latexmk -c foo.tex), and trying different fontspec configurations.

\documentclass{article}

% the following lines were included in:
\usepackage{fontspec}      % A, B, C
\setmainfont{Minion Pro} %    B, C
\setsansfont{Myriad Pro} %       C

\usepackage{lipsum}

\begin{document}
\lipsum
\end{document}


My timing results turned out the same ±1s for three runs each, so I assume they are reliable:

A (just fontspec)  10s
B (+ Minion Pro)   33s
C (+ Myriad Pro)   39s
C (using XeLaTeX)   7s (just as a comparison)


Killing all processes that I knew I could safely kill, including but not limited to things you tend to have open while TeXing like an editor and a browser, brought down compilation times for configuration C to 26s (LuaLaTeX) and 4s (XeLaTeX). (Cf. my comment to topskip)

When the compilation became slow the following lines were displayed in the command line output (the log file contains the same information with a lot more information in between):

luaotfload | Font names database loaded: C:/Users/doncherry/AppData/Local/MiKTeX/2.
9/luatex-cache/generic/names/otfl-names.lua(load: C:/Users/doncherry/AppData/Local/
MiKTeX/2.9/luatex-cache/generic/fonts/otf/temp-minionpro-regular.lua)(load: C:/
Users/doncherry/AppData/Local/MiKTeX/2.9/luatex-cache/generic/fonts/otf/temp-minion
pro-bold.lua)(load: C:/Users/doncherry/AppData/Local/MiKTeX/2.9/luatex-cache/generi
c/fonts/otf/temp-minionpro-it.lua)(load: C:/Users/doncherry/AppData/Local/MiKTeX/2.
9/luatex-cache/generic/fonts/otf/temp-minionpro-boldit.lua)(load: C:/Users/doncher
ry/AppData/Local/MiKTeX/2.9/luatex-cache/generic/fonts/otf/temp-myriadpro-regula
r.lua)(load: C:/Users/doncherry/AppData/Local/MiKTeX/2.9/luatex-cache/generic/fonts
/otf/temp-myriadpro-bold.lua)(load: C:/Users/doncherry/AppData/Local/MiKTeX/2.9/lua
tex-cache/generic/fonts/otf/temp-myriadpro-it.lua)(load: C:/Users/doncherry/AppData
/Local/MiKTeX/2.9/luatex-cache/generic/fonts/otf/temp-myriadpro-boldit.lua)


The keywords cache and temp appearing here made me think there might be some way to store this information permanently so that it doesn't have to be created each time?

I used LuaTeX, Version beta-0.70.2-2012060719 (MiKTeX 2.9) (format=lualatex 2012.9.9) on Windows 7 64 bit. The fonts are the ones provided through Adobe Reader X, manually installed by me to C:\Windows\Fonts.

So my question is: Why is the compilation with LuaLaTeX so slow and can I do anything about that?

-
Depending on the performance of your maching these values seem normal for the first run when the font cache needs to be built. Subsequent runs should only take a few seconds. It seems that, for whatever reason, the font cache is rebuild every time. – Marco Oct 3 '12 at 6:31
In my TeX Live 2012 the font db is generated only during the first run (using the free Minion/Myriad Pro fonts from Adobe). Is it possible you have encountered an instance of this bug? Anyways, there’s still an open issue with performance in general. – Philipp Gesang Oct 3 '12 at 9:25
@Marco: Even subsequent runs can take considerable time; try a \usepackage{libertineotf} as an example. – Martin Schröder Oct 3 '12 at 22:16
A comparable case was observed at tex.stackexchange.com/a/21423/4012 – doncherry Oct 6 '12 at 6:22
The recent versions of lualatex have improved this; there is a noticable speed up. – Andrew Swann Jan 21 '15 at 7:46

## 1 Answer

There are several causes here, but 39 seconds seems way too much. Your log file shows that your files are already in the cache format (temp-fontname.lua).

• fontspec loads a lot of instances during startup (\setmainfont). Each of them takes time.
• memory speed/limit can have a big impact. These lua tables tend to be huge and need to be parsed each time the font loads. If the available memory is limited, even paging might be a problem (though I doubt it is nowadays).

Since XeTeX is so quick, I assume most of the time is spent on the second given point.

-
Just so you get an impression of how huge the font tables can be: in the Context source, the size of a serialized “Zapfino Extra Pro” is specified with 85 MB. – Philipp Gesang Oct 3 '12 at 14:07
The problem is simply because minion is a large font (~1700 glyphs each font)and requires a lot of memory. In fact, Garamond Premier Pro and Arno Pro is even lager, with Luatex you cannot even use them in practice (~4.5 gb memory required). If you want it faster and still use luatex, try find some simpler fonts with less features. Only use Minion when you finalizing the output. – Yan Zhou Oct 6 '12 at 7:07
@YanZhou: If this is the case, then LuaTeX appears to have a huge problem. XeTeX seems to be able to deal with the huge font files just fine. – doncherry Oct 6 '12 at 7:56
@doncherry it's probably not LuaTeX, but luaotfload. While this does not make any difference from a user's point of view, it means that it could probably be fixed one day without rewriting parts of LuaTeX. – topskip Oct 6 '12 at 10:30
@doncherry "Everyone" is well aware of the problem. (Comment: I'll try) – topskip Oct 11 '12 at 7:30