LuaLaTeX Performance-Problem

Klassen und Pakete zur einfachen Umsetzung individueller Vorstellungen


Bianca1504
Forum-Anfänger
Forum-Anfänger
Beiträge: 12
Registriert: Mi 10. Mär 2021, 16:52

Re: LuaLaTeX Performance-Problem

Beitrag von Bianca1504 »

Das heißt, es handelt sich um ein Performance-Problem, das generell beim Kombinieren von scrlayer-scrpage und mathastext unter LuaLaTeX auftritt, und sich mit TeXlive vergleichsweise harmlos, mit MiKTeX jedoch sehr signifikant auswirkt ...


Bianca1504
Forum-Anfänger
Forum-Anfänger
Beiträge: 12
Registriert: Mi 10. Mär 2021, 16:52

Re: LuaLaTeX Performance-Problem

Beitrag von Bianca1504 »

Gute*r Gȧst*in hat geschrieben:
Di 6. Apr 2021, 18:48

Dass mehr zu durchlaufender Code bei TeX zwangsläufig mehr Zeit benötigt, dürfte jetzt nicht so wahnsinnig verwundern. Das ist nicht nur bei LuaLaTeX so. Dramatisch sind die von @MoeWe genannten Unterschiede jetzt IMHO nicht unbedingt, jedenfalls nicht so dramatisch wie bei MiKTeX.

Dass selbst mit TeXlive bei einem Dokument, das keine Mathematik enthält, das Kompilieren bei Verwendung von mathastext ca. 30 bis 50 Prozent länger dauert, als bei Verwendung von microtype (jeweils in Kombination mit scrlayer-scrpage), darf, denke ich, durchaus verwundern. Vom Unterschied, den es mit MiKTeX macht, brauchen wir gar nicht erst zu sprechen.


MoeWe
Forum-Meister
Forum-Meister
Beiträge: 801
Registriert: Fr 30. Aug 2019, 15:35
Kontaktdaten:

Re: LuaLaTeX Performance-Problem

Beitrag von MoeWe »

Mhh, natürlich dauern mehr Seiten länger. Die Idee von mehr Seiten im Test war eher, Einmaleffekte wie Paketladezeit oder äußere Effekte wie Lastschwankungen auszugleichen. Außerdem gibt es so Zahlen, die ich leichter verarbeiten kann: 3 Minuten gegen 2 Minuten kann ich mir besser Vorstellen als 10 Sekunden vs 11 Sekunden, da man da für die Beurteilung der Signifikanz so viele Nachkommastellen mitnehmen muss (ich hab das ja alles manuell gemacht und nicht automatisiert ausgewertet: Vielleicht etwas fürs Wochenende).

Klar ist, dass der Effekt bei TeX Live bei Weitem nicht so krass ist wie mit MikTeX, aber 30% mehr Kompilationszeit pro Seite für das bloße Laden eines Pakets ist schon eine Hausnummer – gerade, wenn es pro Seite ist und kein Einmaleffekt.

Zuletzt geändert von MoeWe am Do 8. Apr 2021, 09:38, insgesamt 1-mal geändert.

MoeWe
Forum-Meister
Forum-Meister
Beiträge: 801
Registriert: Fr 30. Aug 2019, 15:35
Kontaktdaten:

Re: LuaLaTeX Performance-Problem

Beitrag von MoeWe »

Wie dem auch sei, wenn sich jemand die Sache genauer ansehen möchte, könnten folgende (mehr oder weniger durch erratisches Probieren und zufälliges Codebetrachten entstandene) Beobachtungen relevant sein.

Ein großer Teil der Laufzeit scheint von Code zu kommen, den mathastext zu \everymath hinzufügt. Jedenfalls geht

\documentclass{scrbook}

\usepackage[no-math]{fontspec}
\setmainfont{Latin Modern Roman}
\usepackage{lipsum}
\usepackage{mathastext}
\usepackage{scrlayer-scrpage}
\usepackage{luacode}

\begin{document}
\makeatletter
\everymath{}
\makeatother
\begin{luacode}
  for x=1,9 do
    tex.sprint(\luastring{\lipsum[1-150]})
  end
\end{luacode}
\end{document}

wieder schneller.

Der problematische Code scheint \mst@fixmathfonts{} zu sein. Denn auch

\documentclass{scrbook}

\usepackage[no-math]{fontspec}
\setmainfont{Latin Modern Roman}
\usepackage{lipsum}
\usepackage{mathastext}
\usepackage{scrlayer-scrpage}
\usepackage{luacode}


\begin{document}
\makeatletter
\def\mst@fixmathfonts{}
\makeatother
\begin{luacode}
  for x=1,9 do
    tex.sprint(\luastring{\lipsum[1-150]})
  end
\end{luacode}
\end{document}

kompiliert bei mir flugs.

\mst@fixmathfonts wird wie folgt definiert und nur bei LuaLaTeX zu \everymath hinzugefügt

\begingroup
\catcode`N 12
\catcode`O 12
\catcode`D 12
\catcode`E 12
\lowercase{\gdef\mst@fixmathfonts@ #1=NODE;#2#3\relax #4\@empty #5}%
  {\ifx#2\empty\else\font\mst@mathfont=#1=base;#2#3\relax#5=\mst@mathfont\fi}
\lowercase{\gdef\MTfixmathfonts
{\expandafter\mst@fixmathfonts@
  \fontname\textfont\symmtoperatorfont\relax\relax=NODE;\empty\relax\@empty
   {\textfont\symmtoperatorfont}%
 \expandafter\mst@fixmathfonts@
  \fontname\scriptfont\symmtoperatorfont\relax\relax=NODE;\empty\relax\@empty
   {\scriptfont\symmtoperatorfont}%
 \expandafter\mst@fixmathfonts@
  \fontname\scriptscriptfont\symmtoperatorfont\relax\relax=NODE;\empty\relax\@empty
   {\scriptscriptfont\symmtoperatorfont}%
 \expandafter\mst@fixmathfonts@
  \fontname\textfont\symmtletterfont\relax\relax=NODE;\empty\relax\@empty
   {\textfont\symmtletterfont}%
 \expandafter\mst@fixmathfonts@
  \fontname\scriptfont\symmtletterfont\relax\relax=NODE;\empty\relax\@empty
   {\scriptfont\symmtletterfont}%
 \expandafter\mst@fixmathfonts@
  \fontname\scriptscriptfont\symmtletterfont\relax\relax=NODE;\empty\relax\@empty
   {\scriptscriptfont\symmtletterfont}%
  }%
}%
\endgroup
\ifmst@LuaTeX
  \everymath\expandafter{\the\everymath\mst@fixmathfonts}%
  \everydisplay\expandafter{\the\everydisplay\mst@fixmathfonts}%
\fi
\newcommand*\MTfixfonts{\let\mst@fixmathfonts\MTfixmathfonts}%
\newcommand*\MTdonotfixfonts{\let\mst@fixmathfonts\empty}%
\MTfixfonts

Es ist per se nicht weiter verwunderlich, dass Code, der in jedem Mathemodus ausgeführt wird, die Übersetzung langsamer macht. Der Unterschied, den es bei MikTeX macht, ist natürlich schon enorm und vielleicht ist da noch etwas zu holen.

A priori ist mir auch nicht klar, warum scrlayer-scrpage für zusätzliche Mathemodus-Aufrufe sorgt, was hier ja letztendlich die Übersetzungszeit beeinflusst. Allerdings werden in TeX ja einige Dinge über den Mathemodus geregelt, von denen man das nicht unbedingt denken würde. Aber vielleicht ist auch hier Potenzial für Einsparungen. (Wobei das vielleicht nur theoretisch ist, da in dem Beispiel hier scrlayer-scrpage nicht großartig zum Einsatz kommt. Ich kann mir vorstellen, dass es weniger Einsparpotenzial gibt, wenn scrlayer-scrpage echt genutzt wird.)


Benutzeravatar
u_fischer
Forum-Meister
Forum-Meister
Beiträge: 4266
Registriert: Do 22. Nov 2012, 11:09
Kontaktdaten:

Re: LuaLaTeX Performance-Problem

Beitrag von u_fischer »

Ich habe mal ein Issue in fontspec geöffnet https://github.com/wspr/fontspec/issues/442.

Aber mathastext sollte sich auch überlegen, ob man wirklich in jedem \everymath 6 Schriften umsetzen sollte ...


Antworten