# Why is LuaLaTeX so slow and is there anything I can do about it?

A while back I started bumping into issues with LuaLaTex and switched to compiling a project in XeLaTeX. Since then it seems most of my issues have been resolved upstream or are fixable one way on another. It's been suggested that I switch back to avoid some XeLaTeX issues, but speed is one reason that would keep me from doing so. I've gotten almost all the kinks worked out now so my documents compile in either engine, but LuaLaTeX takes over twice as long to do so.

My documents are not long, but they are complicated (example PDF output) involving many rendering passes to fit everything inside of a hard page limit, then doing it all again for other page layouts and content options. A few seconds here and there isn't that big an issue until it adds up to waiting 5 minutes for your documents to be ready for printing instead of 2. I did some testing and it appears this isn't unique to my complicated project. For example this MWE I was using to test ligatures, hyphenation and small-cap font features compiles in 1.29 seconds using XeLaTeX but takes 3.96 seconds in LuaLaTeX!

\documentclass{minimal}
\usepackage{polyglossia}
\usepackage{testhyphens}
\usepackage{libertine}
\setmainlanguage{turkish}
\begin{document}
Uzun---tire. {\scshape Uzun---tire.}
\begin{checkhyphens}{}
İstanbullularınki
İstanbul’lularınki
\end{checkhyphens}
İzmir {\scshape İzmir}
\end{document}


Is this just the way the engine is or am I doing something wrong? If the performance isn't normally so dramatically different, what sort of things might I be looking for to get it setup correctly?

Edit: Based on comments and answers so far it looks like a lot of potentially related issues may be platform specific. I'm particularly interested in problems manifest on and solutions relevant for Linux, although any generally applicable pitfalls or optimizations are welcome.

• – Torbjørn T. Mar 24 '15 at 8:48
• For me both compilations take almost exactly the same amount of time (system 0.1s, real 2.6s) – Andrew Swann Mar 24 '15 at 8:49
• @AndrewSwann I've cleaned up my test by removing all temp files inbetween test runs and run it about 20 times. My first test results seem to be skewed by having just files from previous runs in the folder, but clean tests consistently show a huge difference, not in system time but in user/total run time. XeLaTeX consistently comes in 1.2–1.3 seconds, LuaLaTeX at 1.9–2.2 seconds. Are you using Texlive? I wonder if both of yours are equally slow or equally fast. – Caleb Mar 24 '15 at 9:08
• My timings were with aux files etc. cleaned. Lualatex is actually running slightly faster for me: user 2.4s. This is texlive on a Mac. Lualatex 2014.11.24, xelatex 2014.7.11. – Andrew Swann Mar 24 '15 at 9:13
• @AndrewSwann I just tried this on a Mac too (I think it's installed using Miktex but not sure on that, or even how to tell!) and found much the same results as you. Very comparable times with luatex coming out slightly on top (3.2 vs. 3.6 seconds) most of the time. I'm starting to suspect this is a font and package issue as much as it is an engine issue. – Caleb Mar 24 '15 at 11:41

Running some tests and looking at the output of the process monitor I found that on windows with miktex the "feature" of fontspec to load default settings from a file with the ending .fontspec is slowing down the font search considerably as miktex is looking everywhere for the files. Disabling the feature meant for me that this document needed only around 2.5 seconds instead of 12. In texlive the time gain was 3 seconds instead of 4.6.

\documentclass{article}
\usepackage{fontspec}
\ExplSyntaxOn
{}
\ExplSyntaxOff
\usepackage{libertine}

\begin{document}
abc
\end{document}


# Edit

In the case of miktex there is imho a bug in the file search: unlike pdflatex or xelatex lualatex doesn't rely on the FNDB but starts a real file search in the texmf tree. I made a bug report: https://sourceforge.net/p/miktex/bugs/2356/. In the case of texlive I still have to test if I can improve the compilation time by forcing texlive to use only the ls-R-files.

# Edit 2

One can improve the compilation time in texlive by creating more ls-R-files (at least on my system with quite a lot of local roots ...), but the effect is not so dramatic as the large texmf-trees like texmf-dist already uses only the ls-R.

# Edit 3

Miktex has added a patch to luatex. With todays update it no longers does a slow disk search if a file is not found. The compilation time of a document which loads e.g. libertine dropped from 12 to 3 seconds on my PC ;-).

• That's a great tip!! – percusse Mar 24 '15 at 11:50
• many thanks for the initial answer and the updates. – Mico Mar 26 '15 at 13:06
• The MikTeX problem aside, why would adding additional database files differentially speed up LuaTeX compilation? Does LuaTeX rely on a less efficient search process than pdfTeX, say, for TEXMF trees without ls-R? If so, I'd consider that a bug in itself: not using database files for TEXMFHOME is really extremely convenient and, since the size of the tree is typically small, it should have very low cost in terms of impact on speed of compilation. – cfr Aug 16 '15 at 3:19
• @cfr: luatex was only affected significantly as it looked (due to the fontspec code) for much more non-existing files and as I have a lot of local texmf trees. – Ulrike Fischer Aug 16 '15 at 10:40
• OK. Thanks. So this doesn't explain why it is so much slower generally, I guess. – cfr Aug 16 '15 at 11:46

If you have a Windows system for some reason, font packages are way way slower than finding the actual fonts and installing them as native in the Fonts directory. Here, I've downloaded the OTF version from their website and used

\directlua{starttime = os.clock()}
\documentclass{article}
\usepackage[timer=true]{regstats}
\usepackage{polyglossia}
\usepackage{testhyphens}
%\usepackage{libertine}
\setmainlanguage{turkish}
\setmainfont{Linux Libertine O}
\begin{document}
Uzun---tire. {\scshape Uzun---tire.}
\begin{checkhyphens}{}
İstanbullularınki
İstanbul’lularınki
\end{checkhyphens}
İzmir {\scshape İzmir}
İzmirliler ile burada karşılaşmak çok hoş.
\end{document}


The compilation speeds up 3-5 times depending on the document. As a bonus you get the small caps i (maybe faked from the normal version, I'm not sure).

That probably comes with the price of loosing font properties but check it for yourself if there is any quality change. However in general you can switch back to the original package when you are satisfied with the layout anyways.

I also would like to know why Windows systems has this problem in general.

• Happily I am not on Windows (Texlive on Linux), so this doesn't seem to apply. Başka sakallılarıyla karşılaşmak da hoş! – Caleb Mar 24 '15 at 10:42
• The libertine package sets up much more fonts (and more variants) then a simple \setmainfont, so it is no wonder that it is slower. – Ulrike Fischer Mar 24 '15 at 11:09
• @UlrikeFischer True but also it sets up many options for fontspec too. So I think these checks are done at every compilation instead of checking once and creating a setup file (I'm wildly guessing). – percusse Mar 24 '15 at 11:12

In my case a big reason for slowness in LuaLaTeX is polyglossia. On my (Linux) machine, switching to babel makes compiling up to five times faster for small documents, and generally twice as fast for moderate reports of a few page.

For example the following page :

\documentclass[french,a4paper]{article}
\usepackage{polyglossia}
\begin{document}

\section{Graphe temporel'' / d'activation}
On définit le graphe dirigé acyclique $G_a=(V_a,E_a)$.
\begin{itemize}
\item $V_a$ : points d'interaction.
\item $E_a$ : écoulement entre les points.
\end{itemize}

\section{Graphe hiérarchique}
Graphe de dépendances de données : une fonction a besoin de l'exécution d'une fonction précédente.

Optimisation : passer directement les valeurs. Mais en attendant, on fait du f1 -> store et read -> f2.

\section{Connection entre nœuds}
\begin{itemize}
\item Cas 1 : "optimiste" : on essaye de toujours envoyer les données
\item Cas 2 : "pessimiste" : on n'envoie les données que lorsque tous les nœuds du graphe sont actifs
\item Cas 3 : "retard" : les données sont bufferisées pour envoyer lorsqu'un objet subséquent devient actif. Note : que se passe-t-il si on a plusieurs utilisateurs subséquents ? Est-ce qu'on reprend du début à chauqe fois (le pointeur est dans l'objet situé au bout de l'arête), ou de là ou on s'est arrêté de lire (le pointeur est dans l'objet situé à l'origine de l'arête).
\item Cas 4 : envoyer en parallèle ?
\item Cas 5 : ce qu'il y a actuellement : les noeuds suivants remplacent les résultats des noeuds précédents.
\end{itemize}

Cas ou on a une variable interne au système : on est toujours soit dans le case 2 ou 3.

Cas ou l'utilisateur doit spécifier explicitement les relations de données : 3, 5

Spécification des sous-graphes

Définir l'interface utilisateur
\end{document}


takes on average (five takes) 0.79 seconds to render, and 0.12 second if I switch to babel and remove \usepackage{polyglossia}.

• In my computer using polyglossia makes the compilation slower too. Any solution? – skan May 30 '18 at 13:37
• @skan Did you actually read the answer? – cfr Jun 7 '18 at 1:02
• @cfr yes, but I mean a solution without removing Polyglossia – skan Jun 8 '18 at 1:40
• @skan Fair enough to hope for another answer, but you can't ask for a solution to that problem for this answer because this answer just is: remove polyglossia. So there's no possible edit to it which would make it compatible with not removing polyglossia. I don't see what you expect from this answer. – cfr Jun 9 '18 at 2:58
• as the author of the answer, I would also like to know a way that doesn't require me to remove polyglossia :p I wouldn't say that it's really a solution since lualatex without polyglossia... isn't really lualatex anymore, isn't it ? – Jean-Michaël Celerier Jun 9 '18 at 8:37