Warum dauert das Kompilieren einer LaTeX-Abschlussarbeit länger als 10 Sekunden?

Der kostenlose Tarif von Overleaf bricht inzwischen jede Kompilierung nach 10 Sekunden ab, und viele Arbeiten, die früher problemlos durchliefen, liegen jetzt auf der falschen Seite dieser Grenze. Der übliche Rat lautet, zu bezahlen oder das Dokument zu verkleinern. Die Länge des Textes kostet aber selten die Zeit. Wer ein echtes Projekt Variante für Variante misst, sieht, wo sie hingeht.

Das Projekt ist eine Beispiel-Masterarbeit: vier Kapitel, natbib mit einer .bib-Datei, ein Inhaltsverzeichnis, zwei pgfplots-Diagramme und eine TikZ-Grafik. Kompiliert wird mit Tectonic 0.16.9 auf einem M1-Mac, mit demselben Befehl, den der LaTeX-Tab der osFoundry-Desktop-App ausführt:

let mut cmd = Command::new(executable);
cmd.args(["-X", "compile", "--untrusted", "--outdir"])
    .arg(&root)
    .current_dir(&root)
    .env("TECTONIC_UNTRUSTED_MODE", "1")
    .kill_on_drop(true);

--untrusted schaltet Shell-Escape ab, was weiter unten wichtig wird.

Ein Kompiliervorgang sind drei TeX-Läufe

Das Erste, was das Log zeigt: „Kompilieren“ ist kein einzelner Lauf.

note: Running TeX ...
note: Running BibTeX on main.aux ...
note: Rerunning TeX because bibtex was run ...
note: Rerunning TeX because "main.aux" changed ...
note: Running xdvipdfmx ...

Der erste Durchlauf schreibt Zitierschlüssel und Abschnittstitel in main.aux. BibTeX macht daraus ein Literaturverzeichnis, der zweite Durchlauf setzt es, wodurch sich die Seitenzahlen verschieben, und ein dritter Durchlauf korrigiert dann Inhaltsverzeichnis und Verweise. latexmk und Overleaf durchlaufen dieselbe Schleife. Alles, was im Dokument langsam ist, wird dreimal bezahlt.

Wohin die Zeit geht

Jede Variante wurde zweimal mit warmem Paket-Cache gebaut und mit einer kleinen Schleife gemessen:

for d in full samples-100 csv-table no-figures; do
  ( cd "$d"
    start=$(python3 -c 'import time; print(time.time())')
    TECTONIC_UNTRUSTED_MODE=1 tectonic -X compile --untrusted main.tex > run.log 2>&1
    python3 -c "import time; print('$d', round(time.time() - $start, 1), 's')"
    grep -c 'Running TeX\|Rerunning TeX' run.log )
done

Variante	Gesamter Build	TeX-Läufe
Komplette Arbeit, Diagramme mit samples=500 und samples=300	14.4–15.4 s	3
Dieselben Diagramme mit samples=200 und samples=100	9.2–9.4 s	3
Dieselben Diagramme mit samples=100 und samples=60	7.8 s	3
Dieselben Kurven aus CSV-Dateien gelesen, jeder Punkt erhalten	6.7–6.8 s	3
Ohne Abbildungen (jedes tikzpicture durch einen Kasten ersetzt)	5.5–5.9 s	3
Japanische Fassung der kompletten Arbeit (xeCJK, Hiragino-Schriften)	22.8 s	3

Text, Literaturverzeichnis und Inhaltsverzeichnis zusammen brauchen weniger als 6 Sekunden. Die restlichen 9 gehen an die Abbildungen, und fast alles davon ist pgfplots beim Berechnen der Kurven. Eine Funktionskurve wie {40 + 35*exp(-((mod(x,24)-8)^2)/3) + ...} wird Punkt für Punkt in der Festkomma-Arithmetik von TeX selbst ausgewertet, und zwar in jedem der drei Durchläufe. Dieselben 500 Punkte aus einer Datei zu zeichnen kostet insgesamt etwa eine Sekunde.

samples zu verringern ist der naheliegende Hebel, und er funktioniert auch, man sieht es aber. Bei 100 Stützpunkten werden die Pendlerspitzen im Wochendiagramm zu Ecken. Bei 200 fällt der Build knapp unter 10 Sekunden, und die Kurven sehen fast gleich aus, nur einige kleine Wellen gehen verloren. Die Punkte aus einer CSV zu lesen behält alle und ist schneller als beides:

% before: computed on every pass
\addplot[domain=0:168, samples=500, thick, blue]
  {41 + 33*exp(-((mod(x,24)-8)^2)/3.2) + ...};
% after: the same 500 points, written once by the script that made the data
\addplot[thick, blue] table[x=hour, y=model, col sep=comma]{week.csv};

Bei einer Abschlussarbeit ist das meist ohnehin die ehrlichere Variante, denn die geplotteten Werte stammen ja von Anfang an aus Python oder R.

Die japanische Fassung ist der andere messbare Kostenpunkt: Bei identischen Abbildungen dauert sie etwa 50 % länger als die englische, und die einzigen Unterschiede sind der japanische Text, xeCJK und die Systemschriften, die dabei geladen werden. Auf einem kalten Rechner kommt noch etwas dazu: Beim ersten Tectonic-Lauf mit leerem Cache wurden 427 Paket- und Schriftdateien mit 46 MB heruntergeladen, bevor irgendetwas gesetzt wurde.

Der übliche Fix braucht Shell-Escape

Die Overleaf-Hilfeseite zu Kompilier-Timeouts empfiehlt, TikZ-Bilder auszulagern, sodass jedes nur einmal gebaut und als PDF wiederverwendet wird. Die tikz-Bibliothek external macht das, indem TeX für jede Abbildung einen zweiten TeX-Prozess startet, also einen Shell-Befehl. Unter --untrusted wird das abgelehnt:

warning: chapters/method.tex:20: runsystem(xelatex -halt-on-error -interaction=batchmode -jobname "main-figure0" ...)...disabled.
error: chapters/method.tex:20: Package tikz Error: Sorry, the system call 'xelatex ...' did NOT result in a usable output file 'main-figure0'

Das ist Absicht. Shell-Escape erlaubt es einer .tex-Datei, beliebige Befehle auszuführen. Bei der eigenen Abschlussarbeit ist das in Ordnung, bei einem ZIP, das jemand anderes geschickt hat, nicht. Ohne Shell-Escape geht derselbe Effekt von Hand in zwei Schritten: jede Abbildung in ein eigenes standalone-Dokument legen, es einmal kompilieren und das PDF in der Arbeit mit \includegraphics einbinden.

Den Fehler in einem Projekt mit mehreren Dateien finden

Der letzte langsame Teil ist der Mensch. TeX meldet einen Fehler in der \input-Datei, die es gerade liest, und Tectonic gibt ihn als error: chapters/results.tex:50: Undefined control sequence aus. Das Build-Log der App macht daraus mit einem einzigen regulären Ausdruck eine anklickbare Zeile und fällt auf das klassische TeX-Format zurück, bei dem der Fehler mit ! beginnt und die Zeilennummer ein paar Zeilen später als l.50 folgt:

const tectonic = /^error:\s+(.+?):(\d+):\s*(.+)$/.exec(line)
if (tectonic) return [{ file: tectonic[1].replace(/^\.\//, ''), line: Number(tectonic[2]), message: tectonic[3] }]
if (!line.startsWith('! ')) return []
const next = lines.slice(index + 1, index + 5).find((part) => /^l\.\d+/.test(part.trim()))

Auf dem eigenen Rechner kompiliert, stößt die komplette Arbeit nie an ein Limit von 10 Sekunden. Im kostenlosen Overleaf-Tarif bringt das Plotten aus Datendateien statt aus Formeln diese Arbeit wieder darunter. Die Desktop-App, mit der diese Builds liefen, ist auf der osFoundry-Downloadseite kostenlos.