Kompilierungsgeschwindigkeit optimieren

[HPVD]

Hallo

welche Möglichkeiten gibt es die Kompilierungsgeschwindigkeit bei einem großen Dokument (150Seiten, 100 Bilder: vektor + schrift PDFs aus corel und JPGs) deutlich zu erhöhen?
[Miktex 2.8, pdftex]

Einfache Hardware-Aufrüstung hilft wohl nur begrenzt denn die
Prozessorauslastung ist nie bei 100% mehr bei 60% - trotz schneller Festplatte (konventionell)...
oder??

Woran hängt es?
bzw Welche Ansätze gibt es noch?

die folgenden kenne ich schon:

1) natürlich kann man nur Teile des Dokumentes kompilieren
a) Kapitel in einzelne Dateien und diese mittels include einbinden oder auskommentieren

=> bringt natürlich etwas, ist aber wenn man nicht chronologisch arbeitet nicht wirklich komfortabel

b) mit z.B. Winedt kann man einzelne Absätze setzen

=> bei Gleichungssatz wirksam, die Pakete werden aber ja trotzdem geladen...


2) gerade probiert:
Temporäre Verlagerung des Dokumentes inkl der Bilder auf eine Ram-Disk (Temporäre Festplatte im Arbeitspeicher z.B. mittels http://memory.dataram.com/products-and-services/software/ramdisk/download-ramdisk)

=> Geschwindigkeitsgewinn trotz der vielfachen Geschwindigkeit des RAMs beim "Durchlauf" nicht bemerkbar :-( ??


3) "Draft"option bei den Paketen verwenden: Bilder erscheinen nur als Rahmen...

=> bringt was , jedoch leidet die Übersicht im Dokument und das Schreiben von z.B. Bilddiskussionen wird auch nicht besser wenn man die Bilder im Dokument nicht sieht...


4) schnelleren pdf reader verwenden: sumatra pdf statt acrobat reader

=> bringt etwas, ist jedoch der acrobat einmal geöffnet gewesen (im RAM) dann ist er auch relativ schnell...


Was macht ihr denn damit es schneller geht?
Wie oft kompiliert ihr denn so pro Tag?

Gruß HPVD

PS:
um kein falsches Bild aufkommen zulassen:
ich verwende Latex begeistert seit fast 15 Jahren und insgesamt ist es - neben dem riesigen Qualitäts- und Möglichkeitenvorteil wahrscheinlich auch noch zeitsparend im Vergleich zur Arbeit mit großen Dateien in Word (Stichwort kapitel umstellen + nacharbeit...)
- aber noch etwas schneller beim Kompilieren wäre natürlich noch schöner ;-)

[Stefan_K]

Hast Du schon mal die draft-Option probiert? Da wird auf das Einbinden der Grafiken verzichtet, auch andere Pakete (listings, hyperref) arbeiten dann eingeschränkt, das kann die Übersetzungszeiten während der Entwiclung verkürzen.

Stefan

[HPVD]

mist die hab ich oben nicht genannt:
ja die "Draft"-option habe ich auch schon probiert und nutz ich auch manchmal - aber bilder fördern halt die Übersicht im Dokument drastisch , gerade wenn man an der Bidbeschreibung/Diskussion arbeitet...

Was auch noch etwas bringt, was ich auch mache, ist die Verwendung von sumatra pdf statt den acrobat reader ...

[Füge dies einfach mal oben an - vielleicht kann dass auch mal jemand anders brauchen.]

Gibts weitere Hinweise?
Wieso wird der Prozessor nicht ausgelastet? Sind die vielen kleinen Paket-Dateien auf der Festplatte schuld und gar nicht die Tex-Dateien und Bilder??
=> Dann sollte eine SSD-Festplatte viel bringen.

Aber was gibts denn "Software" seitig??

Danke + Gruß

HPVD

[Schweinebacke]

Der DVI-Modus ist oft erheblich schneller als der PDF-Modus. Wenn also alternativ auch dieser verwendet werden kann, würde ich den mal ausprobieren.

[HPVD]

Der DVI-Modus ist oft erheblich schneller als der PDF-Modus. Wenn also alternativ auch dieser verwendet werden kann, würde ich den mal ausprobieren.

klingt schon sehr verlockend :-)
leider ist das nach meinem Wissen bei Bildern im pdf und jpg format nicht möglich.
Oder gibts da einen Weg bei Beibehaltung des Geschwindigkeitsvorteils?

Gruß HPVD

[rais]

Moin moin,


3) "Draft"option bei den Paketen verwenden: Bilder erscheinen nur als Rahmen...

=> bringt was , jedoch leidet die Übersicht im Dokument und das Schreiben von z.B. Bilddiskussionen wird auch nicht besser wenn man die Bilder im Dokument nicht sieht...

so Dir draft deutlich was bringt, könnte ein Ansatz mit runterskalierten Bildern ausreichen (und wenn Du für Deine Bildformate entsprechende Konsolenprogramme zum Runterskalieren zur Verfügung hast, ließe sich das mit -enable-write18 und ein wenig `zurechtbiegen' des \includegraphics-Befehls auch automatisch erledigen, so die Kompilationszeit durch den zusätzlichen Aufwand zumindest beim ersten Durchlauf in die Länge gezogen würde).

MfG

[HPVD]

Moin moin,

so Dir draft deutlich was bringt, könnte ein Ansatz mit runterskalierten Bildern ausreichen (und wenn Du für Deine Bildformate entsprechende Konsolenprogramme zum Runterskalieren zur Verfügung hast, ließe sich das mit -enable-write18 und ein wenig `zurechtbiegen' des \includegraphics-Befehls auch automatisch erledigen, so die Kompilationszeit durch den zusätzlichen Aufwand zumindest beim ersten Durchlauf in die Länge gezogen würde).

MfG

nicht vor dem Hintergrund Geschwindigkeit, sondern vor dem Hintergrund der Dokumentgröße, hatte ich dazu auch schon einmal einen threat gestartet:

http://www.mrunix.de/forums/showthread.php?t=68737

könntest Du Deine Idee noch etwas detaillieren?

Gruß HPVD

[rais]

Moin moin,

nicht vor dem Hintergrund Geschwindigkeit, sondern vor dem Hintergrund der Dokumentgröße, hatte ich dazu auch schon einmal einen threat gestartet:

`threat' as in `threatening' ? ;-)


könntest Du Deine Idee noch etwas detaillieren?

grob umrissen etwa


%%% mit -shell-escape bzw. -enable-write18 aufzurufen
%
\let\orgincludegraphics\includegraphics
\newcommand*\myfile{}% wird im modifizierten \includegraphics überschrieben
\newif\ifusesmallgraphics
\usesmallgraphicstrue% oder \usesmallgraphicsfalse
\renewcommand*\includegraphics[2][\empty]{%
\edef\myfile{#2-small}%<--ggf. anpassen
\ifusesmallgraphics
\IfFileExists{\myfile.pdf}{%
\ifx#1\empty
\orgincludegraphics{#2}%
\else
\orgincludegraphics[#1]{#2}%
\fi
}{%
\IfFileExists{#1.pdf}{%
\write18{programm-zum-skalieren #1.pdf \myfile.pdf}%
\fbox{Konvertiere `#1' zu `\myfile'\dots}%
}{%
% hier entsprechend auf weitere Formate testen (.png, .jpg)
\typeout{Sorry, weder '\myfile',\MessageBreak
noch '#1' gefunden.}%
}%
}%
\else
\ifx#1\empty
\orgincludegraphics{#2}%
\else
\orgincludegraphics[#1]{#2}%
\fi
\fi
}

also \includegraphics dahingehend umschreiben, daß es bei entsprechend gesetztem Flag (\ifusesmallgraphics) erstmal nachschaut, ob eine wie-auch-immer verkleinerte Bilddatei zur Verfügung steht, wenn ja, wird diese Datei geladen, wenn nicht, wird sie mit `programm-zum-skalieren' erzeugt (wie dieses bei Dir heißen mag, weiß ich nicht)

MfG

[Schweinebacke]

klingt schon sehr verlockend :-)
leider ist das nach meinem Wissen bei Bildern im pdf und jpg format nicht möglich.
Oder gibts da einen Weg bei Beibehaltung des Geschwindigkeitsvorteils?
Im draft-Modus genügt eine eps.bb mit der BoundingBox jeder Grafik oder eine entsprechende Angabe im optionalen Argument von \includegraphics. Für den final-Moduls muss man ggf. mit convert eben eine gering aufgelöste Datei in einem Format erstellen, das vom verwendeten Previewer verstanden wird. Ich würde da auch nicht lange in TeX basteln, sondern das entweder in den build-Prozess einbauen oder einfach einmal für alle oder jede neue Abbildung machen. Den draft-Modus muss man auch nicht zwingend global einschalten, sondern kann ich auch einfach nur beim Laden von graphicx mit angeben, damit er nur dafür gilt.

[cookie170]

Es gibt ein paar Pakete, die pdftex beschleunigen, z.B.

http://www.tex.ac.uk/tex-archive/help/Catalogue/entries/mylatexformat.html

Gruß,
Alexander