Observed durations of \setmainfont et al. feel big
#528
Comments
|
It's been quite some time since I looked at profiling this code. I did have some l3benchmark hooks here and there at some point to figure out where the problems were (although I suspect unicode-math was where the main issues were found). fontspec does do some speculative font loading, and I believe there might be some lingering caching issues where loading the same font with the same features shouldn't re-process everything (but actually it does). My guess is that you might see some speed up if you explicitly specify the italic, bold, etc., shapes — it might be slow to use engine lookups for them. Sadly I don't have free cycles right now to tear apart the code line by line but I'm happy to keep this issue open to look into it in the future. |
|
I tried specifying the italic, bold and bold-italic explicitly, and it did not change much: and I had to remove spaces from name (with xelatex, and I left it this way for lualatex). Maybe I should have added Extension=.ttf or Path? Here is test file \documentclass{article}
\usepackage{pdftexcmds}
\usepackage{iftex}
\makeatletter
\let\pdfresettimer\pdf@resettimer
\let\pdfelapsedtime\pdf@elapsedtime
\makeatother
\usepackage{fontspec}
\pdfresettimer
\setmainfont{DejaVuSerif}[
RegularFont=*,
BoldFont=*-Bold,
ItalicFont=*-Italic,
BoldItalicFont=*-BoldItalic,
]
\typeout{(\ifxetex xelatex \else lualatex \fi 1)\the\dimexpr \pdfelapsedtime sp\relax}
\pdfresettimer
\setsansfont{DejaVuSans}[
RegularFont=*,
BoldFont=*-Bold,
ItalicFont=*-Oblique,
BoldItalicFont=*-BoldOblique,
]
\typeout{(\ifxetex xelatex \else lualatex \fi 2)\the\dimexpr \pdfelapsedtime sp\relax}
\pdfresettimer
\setmonofont{DejaVuSansMono}[
RegularFont=*,
BoldFont=*-Bold,
ItalicFont=*-Oblique,
BoldItalicFont=*-BoldOblique,
]
\typeout{(\ifxetex xelatex \else lualatex \fi 3)\the\dimexpr \pdfelapsedtime sp\relax}
\pdfresettimer
\usepackage{unicode-math}
\typeout{UNICODE-MATH: \the\dimexpr\pdfelapsedtime sp\relax}
\begin{document}
nothing to worry \textsf{about}? \texttt{mono}
\end{document}luaotfload seems to put strange warnings in log but this is probably some other problem |
|
I said I didn't have time to profile this, and I don't, but I tried this and found that there is a small part of the code which appears to be responsible for 50% of the font loading time: On my new-ish Mac mini, this gives: Do you see a similar performance hit for the |
|
Here is typical output on my very old hardware. It appears my estimate current PCs would be about 4X faster was not that far off! ... and yes, sorry, I do obtain similar findings on my equipment, with some interesting difference between xelatex and lualatex. (inclusive of a blank line in output which I have not tried to understand). For xelatex: For lualatex: |
Description
Recently I worked on some project using lualatex and noticed during each build a systematic apparent "freeze" of one to two seconds right after having loaded unicode-math-table.tex. For a long time I blamed (this was silly) that file but now I understand it is
\setmainfontet al. which were responsible for it all:I have commented out here the fallback business (which exacerbates the situation but does not cause it) to focus on simpler configuration. I tested with TeX Gyre Termes too and found faster times but in my view "problem" persists.
fontspecis definitely not responsible for my lack of upgrade to my hardware, which I admit is currently quite outdated (2Ghz single core CPU at this time), and the timings would certainly be divided by at least 2, probably 5 on current CPUs.Still a single
\setmainfontor cousin costs an amount of time similar to loading all ofunicode-mathfor example (from half as much to twice as much, with lualatex).Check/indicate
Minimal example demonstrating the issue
Here is my test file
Typical console output with lualatex (
ptis to be read assecond)and with xelatex
Further details
With original context of lualatex with fallback config, the three font definitions ended up costing about 1s to 1.5s.
This is not an issue report but a question to learn if some profiling has been done to identify what causes observed execution times. Is it mostly engine issue, or at macro layer? "One second" is a lot of time when watching console output during preamble execution.
The text was updated successfully, but these errors were encountered: