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?

Henri Menke
  • 109,596
doncherry
  • 54,637
  • 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 Oct 03 '12 at 06: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. – Philipp Gesang Oct 03 '12 at 09:25
  • In comparison with PDFTeX, LuaTeX loads system fonts (that's probably no news), so if you have tons of system fonts (Adobe font catalogue, anyone?), then it takes a lot of time to index. – raphink Oct 03 '12 at 12:12
  • 1
    @Marco: Even subsequent runs can take considerable time; try a \usepackage{libertineotf} as an example. – Martin Schröder Oct 03 '12 at 22:16
  • 1
    A comparable case was observed at http://tex.stackexchange.com/a/21423/4012 – doncherry Oct 06 '12 at 06:22
  • 2
    The recent versions of lualatex have improved this; there is a noticable speed up. – Andrew Swann Jan 21 '15 at 07:46
  • @AndrewSwann, it is still slow in TL2014, though perhaps not that slow (I obviously cannot test the OP's system). Are you using some TL2015 beta version? – Gaussler May 29 '15 at 18:14
  • 1
    @Gaussler No, my remark was about the TL2014 version, which I found significantly quicker that earlier ones. – Andrew Swann May 29 '15 at 19:47
  • @AndrewSwann Okay, I agree the 2014 version is usable, yet still significantly slower than its cousin engines. Let us just hope that TL2015 resolves some of this. – Gaussler May 29 '15 at 19:53
  • Update: It did not; I don't feel any difference in TL15 at least. – Gaussler Jun 17 '15 at 16:08

1 Answers1

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.

topskip
  • 37,020
  • 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. – Philipp Gesang Oct 03 '12 at 14:07
  • I have 2x2GB @ 800Mhz, on a 64-bit laptop from 2009. Even though I'm not exactly an expert on computer parts, I was hoping this would be sufficient for a TeX flavor. I went ahead and killed 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. For configuration C, compilation times went down to 26s (LuaLaTeX) and 4s (XeLaTeX). Peak memory usage during compilation with LuaLaTeX was 1.80 GB. Does this data tell you anything more about the problem? – doncherry Oct 06 '12 at 06:22
  • 1
    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 06 '12 at 07: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 Oct 06 '12 at 07: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 Oct 06 '12 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 Oct 06 '12 at 14:03
  • @YanZhou + topskip: Well, but the bottom line is there is nothing for me to do right now? topskip, I think you have good connections to the LuaTeX (and luaotfload) devs, could you make sure they're aware of the dimensions of this issue? Also, I've accepted your answer, do you think you could add a brief summary of the information from these comments? – doncherry Oct 11 '12 at 04:47
  • 2
    @doncherry "Everyone" is well aware of the problem. (Comment: I'll try) – topskip Oct 11 '12 at 07:30
  • Any alternative to "luaotfload"? – skan Aug 30 '15 at 17:20