编辑

编辑

不久前我开始撞击进入问题我用 LuaLaTex 编译项目,然后切换到用 XeLaTeX 编译项目。从那时起,似乎我的大部分问题都已在上游得到解决,或者可以通过某种方式修复。有人建议我改回来,以避免一些 XeLaTeX 问题,但速度是阻止我这样做的一个原因。现在我已经解决了几乎所有问题,所以我的文档可以在任何一个引擎中编译,但 LuaLaTeX 需要两倍多的时间才能完成。

我的文件不长,但是很复杂(PDF 输出示例) 涉及许多渲染过程将所有内容都放入硬页面限制内,然后对其他页面布局和内容选项重复上述操作。这里那里的几秒钟不是什么大问题,直到加起来等待 5 分钟才能打印文档,而不是 2 分钟。我做了一些测试,似乎这并非我复杂项目所独有的。例如,我用来测试连字、连字符和小写字体功能的 MWE 使用 XeLaTeX 在 1.29 秒内编译,但在 LuaLaTeX 中需要 3.96 秒!

\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}

引擎就是这样的吗,还是我做错了什么?如果性能通常不会有如此大的差异,我可能需要寻找哪些东西才能正确设置它?

编辑:根据目前的评论和回答,许多可能相关的问题可能与平台有关。我对 Linux 上出现的问题和相关解决方案特别感兴趣,尽管欢迎任何普遍适用的陷阱或优化。

答案1

运行一些测试并查看进程监视器的输出后,我发现在装有 miktex 的 Windows 上,fontspec 的“功能”会从以 结尾的文件加载默认设置,这.fontspec大大减慢了字体搜索速度,因为 miktex 会到处查找文件。禁用该功能对我来说意味着此文档只需要大约 2.5 秒,而不是 12 秒。在 texlive 中,时间增益是 3 秒,而不是 4.6 秒。

\documentclass{article}
\usepackage{fontspec}
\ExplSyntaxOn
\cs_set:Nn \__fontspec_load_external_fontoptions:Nn
 {}
\ExplSyntaxOff
\usepackage{libertine}


\begin{document}
abc
\end{document}

编辑

在我看来,miktex 的文件搜索中存在一个错误:与 pdflatex 或 xelatex 不同,lualatex 不依赖于 FNDB,而是在 texmf 树中启动真正的文件搜索。我提交了一个错误报告:https://sourceforge.net/p/miktex/bugs/2356/. 在 texlive 的情况下,我仍然需要测试是否可以通过强制 texlive 仅使用 ls-R 文件来改善编译时间。

编辑2

通过创建更多的 ls-R 文件,我们可以缩短 texlive 中的编译时间(至少在我的系统上有相当多的本地根...),但效果并不那么显著,因为像 texmf-dist 这样的大型 texmf 树已经只使用了 ls-R。

编辑3

Miktex 已为 luatex 添加了一个补丁。通过今天的更新,如果找不到文件,它不再进行缓慢的磁盘搜索。在我的 PC 上,加载例如 libertine 的文档的编译时间从 12 秒缩短到 3 秒 ;-)。

答案2

如果你有 Windows 系统,字体包会比在 Fonts 目录中找到实际字体并将它们安装为原生字体慢得多。在这里,我从他们的网站下载了 OTF 版本并使用

\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}

根据文档的不同,编译速度可提高 3-5 倍。作为奖励,您可以获得小写字母 i(可能是从正常版本伪造的,我不确定)。

这可能伴随着失去字体属性的代价,但请自行检查是否有任何质量变化。不过,一般来说,如果您对布局感到满意,您可以切换回原始包。

我也想知道为什么Windows系统普遍存在这个问题。

答案3

在我看来,LuaLaTeX 运行缓慢的一大原因是多语种。在我的 (Linux) 机器上,切换到 babel 可以使小文档的编译速度提高五倍,而几页的中等报告的编译速度通常会提高一倍。

例如以下页面:

\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}

平均 (五次) 需要 0.79 秒来渲染,如果我切换到 babel 并删除 ,则需要 0.12 秒\usepackage{polyglossia}

相关内容