LuaLaTeX Performance-Problem

Antwort erstellen


Diese Frage dient dazu, das automatisierte Versenden von Formularen durch Spam-Bots zu verhindern.
Smilies
:D :) :( :o :shock: :? 8) :lol: :-x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen:

BBCode ist eingeschaltet
[img] ist eingeschaltet
[flash] ist ausgeschaltet
[url] ist eingeschaltet
Smilies sind eingeschaltet

Die letzten Beiträge des Themas

Ich habe die Datenschutzerklärung gelesen und bin damit einverstanden.

   

Wenn du eine Datei oder mehrere Dateien anhängen möchtest, gib die Details unten ein.

Ansicht erweitern Die letzten Beiträge des Themas: LuaLaTeX Performance-Problem

Re: LuaLaTeX Performance-Problem

von u_fischer » Mi 7. Apr 2021, 11:54

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 ...

Re: LuaLaTeX Performance-Problem

von MoeWe » Mi 7. Apr 2021, 09:32

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.)

Re: LuaLaTeX Performance-Problem

von MoeWe » Di 6. Apr 2021, 22:53

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.

Re: LuaLaTeX Performance-Problem

von Bianca1504 » Di 6. Apr 2021, 21:33

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.

Re: LuaLaTeX Performance-Problem

von Bianca1504 » Di 6. Apr 2021, 21:27

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 ...

Re: LuaLaTeX Performance-Problem

von Gute*r Gȧst*in » Di 6. Apr 2021, 20:38

Inzwischen ist die Installation fertig. Mit TeX Live 2021 unter Windows 10 ist das Ergebnis vergleichbar mit dem im Online-Editor, sprich: Mit Verwendung von scrlayer-scrpage + mathastext dauert die Ausgabe aller Seiten ca. 30% länger als ohne die beiden Pakete. Das ist also weit weniger dramatisch als bei MiKTeX.

Re: LuaLaTeX Performance-Problem

von Gute*r Gȧst*in » 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.

Ich bin leider noch nicht dazu gekommen, mit TeX Live unter Windows zu testen. Die Installation ist irgendwann stehen geblieben bzw. die benötigte Zeit sprang irgendwann auf über 5 Stunden. Irgendwie tröpfeln die Pakete jetzt nur noch. Ich habe wohl einen schlechten Server erwischt. Derzeit wird tie installiert.

Re: LuaLaTeX Performance-Problem

von MoeWe » Di 6. Apr 2021, 17:08

Hab den Tag über nebenbei auf dem Arbeitsrechner (Laptop, Ubuntu 18.04, i5-8250U) mit ganz frischem TeX Live 2021 ein paar Tests laufen lassen. Mit dem ursprünglichen Beispiel fand ich den Effekt zu klein, um ihn nicht auch auf Auslastungsschwankungen zurückzuführen, aber mit for x=1,90 do zeigt sich meiner Meinung nach ein deutlicheres Bild: die Laufzeit für ca. 2300 Seiten beträgt

  • mit allen Paketen etwa 3min 25sek,
  • ohne mathastext um die 2min 10sek,
  • ohne scrlayer-scrpage ca. 2min 5 sek.

Die Durchläufe habe ich natürlich mehrfach gemacht, das sind in etwa die Mittel.

Der Unterschied bei den letzten beiden Punkten scheint mir jetzt auf den ersten Blick nicht signifikant, aber mit beiden Paketen braucht es schon deutlich länger.

Unter etwas größerer Last (Videokonferenz) dauert es schon mal länger. Da hat es mit allen Pakete etwa 8min 55sek und ohne mathastext 6min 20sek gedauert. Aber da ist die Vergleichbarkeit nicht so gut gegeben.

Re: LuaLaTeX Performance-Problem

von Bianca1504 » Di 6. Apr 2021, 16:23

Nicht ganz neu hier hat geschrieben:
Di 6. Apr 2021, 15:10

Warum wird eigentlich in dem Beispiel \setmainfont{Latin Modern Roman} verwendet? Ich dachte, das wäre die Voreinstellung mit fontspec. Wenn ich das rauslasse, ist das Beispiel bei mir mit MiKTeX extrem viel schneller.

Ich habe "Latin Modern Roman" eingetragen, damit das Beispiel unverändert auf jedem System kompiliert werden kann. Selbst wenn ich einen Windows-System-Font genommen hätte, wäre der vielleicht auf Linux oder MacOS nicht vorhanden gewesen. Wenn man keinen Font definiert, verschwindet das Problem zwar (vermutlich weil mathastext dann gar nicht erst aktiv wird), aber die Nutzung von im OS installierten Fonts mittels fontspec ist ja einer der wichtigsten Gründe, überhaupt LuaLaTeX zu verwenden.

Re: LuaLaTeX Performance-Problem

von u_fischer » Di 6. Apr 2021, 15:15

Nicht ganz neu hier hat geschrieben:
Di 6. Apr 2021, 15:10

Warum wird eigentlich in dem Beispiel \setmainfont{Latin Modern Roman} verwendet? Ich dachte, das wäre die Voreinstellung mit fontspec. Wenn ich das rauslasse, ist das Beispiel bei mir mit MiKTeX extrem viel schneller.

Ja, aber das Beispiel soll ja demonstrieren, dass miktex unter bestimmten Bedingungen langsam ist. Da wäre es nicht so sinnvoll die Störfaktoren alle wegzulassen. Und mit anderen Schriften hat man den Effekt auch.


Nach oben