Are pdfLaTeX, XeLaTeX and LuaLaTeX getting (much) slower in macOS?

Question

SOLVED: see bottom of message!

I sensed pdfLaTeX was slower in TeX-Live 2020 and decided to run some benchmarking…

• Computer: MacBook Pro (2018) with SSD
• Document: The "novathesis" thesis template
• LaTeX Version(s): MacTex 2019, 2020, 2021 (all versions up to date)

The chart shows the execution time (as the average of 5 consecutive runs) for pdfLaTeX, XeLaTeX and LuaLaTeX, versions 2019, 2020 and 2021.

My reading of the charts is:

1. pdfLaTeX and XeLaTeX go side-by-side on execution times (XeLaTeX is becoming slightly faster);
2. pdfLaTeX and XeLaTeX are getting slower with each release (with a huge slowdown for 2020);
3. The slowdown in LuaLaTeX is less noticeable and in macTeX 2020 LuaLaTeX is competing with pdfLaTeX and XeLaTeX (by demerit of pdfLaTeX and XeLaTeX that became much slower).

Questions:

1. Do you have a similar experience?
2. What happened to pdfLaTeX and XeLaTeX to suffer such a slowdown?

UPDATE

Another benchmarking, now with (almost) no additional packages. Used the average of 5 runs, in same computer, with the code below (BTW, the resulting PDF is 545 pages):

\documentclass{article}
\usepackage{lipsum}
\begin{document}
    \newcounter{int}
    \setcounter{int}{1}
    \loop
        \lipsum[1-30]
        \addtocounter{int}{1}
        \ifnum \value{int}<100
    \repeat
\end{document}

Execution times below:

My reading from the numbers above is that the pdf/Xe/Lua-LaTeX engines are not getting slower. But as a user, I'm experiencing a considerable slowdown overall… Can it really be from kpsewhich? How to measure/evaluate that?

Answer 1

The problem was in latexmk 58886 (4.72b), which when applied made the compiling time of my document increase from 32 to 76 seconds. The current update of latexmk 59081 (4.73) solves the issue. 😃

The reason for the slowdown (and the fix) is in the changelog entry for version 4.73:

## 30 Apr 2021 John Collins  Revert the change of 14-15 Apr, by removing the
##                           of cwd().  That gave sometimes obnoxiously slow
##                           parsing of big log files, because of the slowness
##                           of large number of calls to cwd() caused by calls
##                           to sub normalize_filename. I think I am mistaken
##                           that cwd() could possibly give a different result
##                           than getcwd(), whose cached result is used by
##                           my goodcwd(). That idea was my motivation on 14 Apr.