46

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?

10
  • 1
    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
    Commented Oct 3, 2012 at 6:31
  • 3
    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. Commented Oct 3, 2012 at 9:25
  • 1
    @Marco: Even subsequent runs can take considerable time; try a \usepackage{libertineotf} as an example. Commented Oct 3, 2012 at 22:16
  • 1
    A comparable case was observed at tex.stackexchange.com/a/21423/4012
    – doncherry
    Commented Oct 6, 2012 at 6:22
  • 2
    The recent versions of lualatex have improved this; there is a noticable speed up. Commented Jan 21, 2015 at 7:46

1 Answer 1

20

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.

9
  • 2
    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. Commented Oct 3, 2012 at 14:07
  • 13
    @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
    Commented Oct 6, 2012 at 7:56
  • 3
    @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
    Commented Oct 6, 2012 at 10:30
  • 2
    @doncherry xetex use system libraries to load and render font. Luatex convert all font data to huge lua table, it make use fontforge's library. In short, luatex's approach is more flexible (you can patch the lua font table if you really need), and perhaps more portable, but the performance is nowhere close to xetex.
    – Yan Zhou
    Commented Oct 6, 2012 at 14:03
  • 2
    @doncherry "Everyone" is well aware of the problem. (Comment: I'll try)
    – topskip
    Commented Oct 11, 2012 at 7:30

You must log in to answer this question.

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