Kompilier- und Linkgeschwindigkeit

[Psycho]

Hallo.

Ich nutze hauptsächlich Visual Studio 2008 mit C++. Jetzt habe ich aber eine fremde Bibliothek benutzt, die in .NET geschrieben wurde (managed code).
Damit ich die in meinem C++-Programm nutzen kann, bin ich wie in der MSDN beschrieben vorgegangen. Ich habe also eine neue C#-DLL erstellt, die eine Referenz auf die DLL enthält, die ich tatsächlich benutze. Meine DLL stellt dann das COM-Interface zur Verfügung, welches ich im C++-Programm benutze.
Zu meiner Überraschung hat das alles auch auf Anhieb geklappt.

So, nun zum Thema: Da dies mein erstes C#-Projekt war, war ich sehr verärgert darüber, wie schnell die Bibliothek erstellt wurde. F7 gedrückt, zack war sie schon fertig. Verärgert deswegen, weil mein C++-Programm ca ne halbe Minute braucht, bis endlich eine Mini-Änderung kompiliert wurde. Ich mache sehr oft kleine Änderungen. Jetzt bin ich neidisch auf C#. Wobei das C#-Projekt natürlich deutlich kleiner ist als mein C++-Programm.

Ich benutze vorkompilierte Header. Trotzdem dauert der Build-Vorgang recht lange, besonders "Generating Code" (ich glaub das macht der Linker) dauert ewig und ich hab keine Ahnung was der da macht. Bzw wenn der den Code erstellt, was hat dann der Compiler gemacht? Visual C++ 6 kann zwar keine Templates, war dafür aber viel schneller was das anbelangt.

Kennt ihr Tipps, um den Build-Vorgang zu beschleunigen?

[Schrompf]

Falls "Generating Code" so lange dauern sollte, baust Du wohl eine Release-Version mit Link Time Code Generation. Das kann eine Weile dauern. Baue einen Debug-Build und schau, wie lange der braucht. Nutze außerdem unbedingt das parallele Bauen. Von Haus aus baut Visual Studio nur separate Projekte parallel. Es gibt aber eine Kommandozeilenoption, die man irgendwo in den Projekteinstellungen hinzufügen muss, damit er auch Files innerhalb ein- und desselben Projekts parallel baut.

C++ wird aber beim Build prinzipiell IMMER sehr viel langsamer sein als C#. Das ist schlicht bedingt durch die von C geerbte Modularisierung, nach der in jeder Kompiliereinheit (.cpp-File) alle benötigten Definitionen bekannt sein müssen. Das passiert per Include, und Includes benötigen wiederrum andere Includes, usw. Das läuft bei einem Projekt üblicher Größe darauf hinaus, dass pro CPP-File x Megabyte an Headern geparst werden müssen. Selbst vorkompiliert ist das ein ziemlicher Datenbrocken. Zudem ist die Sprache C++ sehr viel komplexer, speziell bei Templates und all dem Meta-Kram, den man damit anstellen kann. Du wirst also nie auf das Kompiliertempo von C# kommen, egal was Du tust.

[kimmi]

Man kann das Compilieren und das Linken aber in der Regel etwas optimieren:

• Include auf das Nötigste minimieren, nur das includieren, was man auch wirklich braucht.
• In Header-Files so weit es geht Forward-Deklarationen benutzen, die Header dann im Cpp-File erst inkludieren. Das gilt gerade für oftmals inkludierte Header.
• Zyklische Compile-Abhängigkeiten vermeiden, diese Zyklen versuchen, durch Layering zu ersetzen.
• Lange inlines vermeiden.
• Zyklische Link-Abhängigkeiten vermeiden.
• So weit es geht den Code orthogonal, d.h. weitesgehenst entkoppelt, schreiben, um von vorn herein die Abhängigkeiten zu minimieren.
• Wie Schrompf bereits gesagt hat: parallel bauen!

In diesem Buch werden einige Sachverhalte diesbezüglich mehr oder weniger anschaulich dargelegt:
http://www.amazon.de/Large-Scale-Softwa ... 0201633620

Gerade bei sehr großen Projekten wird der Linker irgendwann gern der Flaschenhals. Hier vor Ort dauert ein Build gern mal 7-8 Stunden.

Gruß Kimmi

[Helmut]

Du kannst auch versuchen, eine Cpp Datei zu erstellen, in der du alle deine bisherigen CPP Dateien inkludest. Dann musst du nur noch diese eine Datei kompilieren. Das sollte die Sache erheblich beschleunigen, es dauert dann aber jedesmal genausolange, auch wenn du nur einen Kommentar in einer CPP veränderst. Vorteil ist hier auch, dass man sich nicht für jede Datei mit den Includes ärgern muss, denn die Tipps von Kimmi umzusetzen ist echt nervig und wird einem nur sehr mäßig belohnt.

Ansonsten wurde die Linkzeit angeblich im neuen VS2010 verbessert, kannst du ja mal ausprobieren (zZ ja kostenlos). Oder du benutzt (, wie ich;)) VS2005, das ist soweit ich weiß auch etwas schneller als 08.

Ciao

[Chromanoid]

steig doch einfach auf c# um :)
in java (wahrscheinlich auch bei c#) muss man bei einer vernünftigen ide-konfiguration übrigens gar nicht mehr aufs kompilieren warten, da beim speichern der dateien immer im hintergrund kompiliert wird. Fehler sieht man so sofort nach dem abspeichern und man kann beim testen sogar teile des codes austauschen ohne das programm neustarten zu müssen :)...

[kimmi]

@Helmut
Hm, die von mir aufgeführten Tipps haben natürlich auch gerade bezüglich Wartbarkeit der Software echte Vorteile, die man gerade bei größer werdenen Projekten nicht unterschätzen sollte. Gerade entkoppelte Komponenten und der Einsatz von Interfaces ( Stichwort Dependency Injection, hatte ich oben noch nicht aufgeführt ) erhöhen unter anderem auch die Testbarkeit einer Software. Und das Zusammenschmeißen aller Sourcen in ein File erfordert bei jeder noch so kleinen Änderung einen kompletten Rebuild. Aber jedem das seine :).

Gruß Kimmi

[Krishty]

Schrompf hat Recht, man wird die Kompilierzeit niemals unter die von C# drücken können. Auch, wenn kimmis Tipps positive Nebenwirkungen haben, die Kompilierzeit reduziert sich dadurch auch nicht so stark, wie man zuerst meinen könnte.

Das meiste Optimierungspotential sehe ich bei den Kompilierungsoptionen: Wenn du bei normalen Builds LTCG eingeschaltet hast, ist es kein Wunder, dass das Linken ewig dauert. Weg damit. Schrompfs Empfehlung für paralleles Kompilieren befolgen. „Enable minimal Rebuild“ einschalten. Alle Optimierungen aus. Es kann auch helfen, sich eine (RAM-)Partition mit ein bis zwei GiB exklusiv für die temporären Build-Dateien anzulegen … die fragmentieren schließlich wie nichts Gutes und die Festplatte ist meist Limitierung Nummer eins.

Denk auch drüber nach, ob du nicht vielleicht mit Edit & Continue was anfangen könntest …

… und wenn du Rapid Prototyping betreibst, lager den entsprechenden Programmteil aus dem Quellcode aus. Ob das bedeutet, dass du Lua benutzt oder eine C#-DLL oder sonstwas, hängt vom Anwendungszweck ab. (Ich habe da ein Bild von den Leuten im Kopf, die ihre Shader als C-Strings hardcoden und ihre Programme 200 Mal kompilieren, statt die Shader in Textdateien auszulagern.)

Dass kompilieren & linken in VS2010 schneller geht, kann ich eigentlich nicht bestätigen.

Gruß, Ky

[kimmi]

An die BuilIch kann den anderen zu beipflichten, an C# wird man mit meinen Tipps nicht herankommen. Hält man sich an sie, exkalieren die Buildzeiten nicht komplett :).

Gruß Kimmi

[Psycho]

Falls "Generating Code" so lange dauern sollte, baust Du wohl eine Release-Version mit Link Time Code Generation.

Aha. Hätt ich ma alle Optionen durchchecken sollen. Vielen Dank, genau das LTCG brauch ich nicht.

C++ wird aber beim Build prinzipiell IMMER sehr viel langsamer sein als C#.

Interessant, dass ihr euch da alle so einig seid. Klar, C# kann sich den Schritt von Intermediate Language -> x86 sparen, aber vom Prinzip müsste sich doch eine C++-Datei genau wie eine C#-Datei parsen lassen, wenn man denn wollte...

Das ist schlicht bedingt durch die von C geerbte Modularisierung, nach der in jeder Kompiliereinheit (.cpp-File) alle benötigten Definitionen bekannt sein müssen.

...denn der Compiler (oder ein Programm, welches beides macht, kompilieren und linken) kann ja genauso wie bei C# ja erstmal davon ausgehen, dass das alles noch kommt, was so an Klassen verwendet wurde, und einen eventuellen Fehler einfach später melden.

Kimmi: Danke, einige Tipps beherzige ich bereits und teilweise gehen sie ja einher mit gut strukturierter Programmierung.

Du kannst auch versuchen, eine Cpp Datei zu erstellen, in der du alle deine bisherigen CPP Dateien inkludest.

Ne danke, solche Hacks überlass ich gerne dem Compiler, falls er sie denn anbieten sollte.

steig doch einfach auf c# um

Aber ich mag C++ doch so (bis auf die ganzen Ausnahmen, die es so umständlich machen zu schreiben).
In Java habe ich während der letzten beiden Semester reingeschnuppert und war sehr positiv überrascht, besonders von Eclipse. Aber das ist ein anderes Thema, sonst sind wir gleich im Java-Thread.

(Ich habe da ein Bild von den Leuten im Kopf, die ihre Shader als C-Strings hardcoden und ihre Programme 200 Mal kompilieren, statt die Shader in Textdateien auszulagern.)

MessageBox(0,L"me was executed",0,0);
Na und?

Also, ich habe tatsächlich meistens als Release kompiliert. Jetzt habe ich auf Debug umgestellt, und es scheint wirklich schneller zu sein.
Leider bekomm ich, sobald ich einen kompletten Rebuild mache, den Fehler im Anhang.
Drücke ich anschließend nochmal auf "Erstellen", klappt der Link.

Poah, jetzt gerade einmal mein Programm gestartet: Ist bestimmt um Faktor 5-10 langsamer. Ich verarbeite einige Screenshots (10-20), die jeder so 7 MB groß sind. Da bleib ich lieber im Release und stelle nur das LTCG aus.

[Schrompf]

Wie debugst Du denn bisher? Standard ist wirklich der Debug-Build, den benutzt man in 90% der Fälle beim Entwickeln. Eine Release mit allen Optimierungen baut man nur hin und wieder, wenn die Entwicklung einen soliden Zwischenstand erreicht hat. Wir haben uns zusätzlich eine dritte Build-Konfig gebastelt, die wir Relug genannt haben. Grundlegende Optimierungen und inlining, aber auch alle Debug-Symbole und keine LTGC. Ist etwa halb so schnell wie die volloptimierte Release, damit kann man auch gut arbeiten.

[Psycho]

Bei meinem aktuellen Projekt habe ich immer mit dem Release-Modus gearbeitet, nur mit zusätzlichen Debug-Infos (.pdb), so dass mir Olly die Namen der Funktionen anzeigen kann.
Ich werde mir auch mal eine neue Konfiguration anlegen und sehen, was genau ich brauche. So nen doppelten Runtime-Check auf Speicherüberschreibungen auf dem Stack wohl eher nicht zB.
Wenn ich dann auch bei halb so schnell rauskomme, wär ich zufrieden.

Da der Debug-Mode so langsam lief, habe gestern auch das erste Mal den Profiler von MS ausprobiert. Naja ich find den nicht so prall. Zuerst einmal ist der im VS Pro nicht dabei, sondern muss manuell runtergeladen werden. Dann hat er keinerlei Integration in VS, sondern muss per Kommandozeile bedient werden. Dann gibt es nicht einen Befehl, der einem ein Ergebnis ausspuckt, sondern 2-3 in Reihe, dann hat man .csv-Dateien. Richtig gut interpretierbar waren die aber auch nicht. Werds aber nochmal probieren, er hier bekommt immerhin richtig schön auswertbare Reports.

Wegen inlining: Ich kenn mich mit dem Thema nicht so aus, aber ganz ehrlich, eigentlich möchte ich dem Compiler nicht sagen müssen, was er inlinen soll. Das soll er, wenns nach mir geht, komplett selber entscheiden. Er sieht ja selber, welche Funktionen besonders kurz sind und oft aufgerufen werden.

[Lord Delvin]

Er sieht ja selber, welche Funktionen besonders kurz sind und oft aufgerufen werden.

Naja das Problem ist für nen statischen Compiler nicht entscheidbar. Du kannst kurze Funktionen inlinen, aber du kannst nicht wissen, wie oft welche funktionen aufgerufen werden, es sei denn es gibt überhaupt nur eine stelle von wo die funktion aufgerufen wird, allerdings hab ich auch in dem fall schon gesehen, dass der Compiler nicht selbst drauf kommt da inline hinzuschreiben. Gut die funktion hatte auch 5 Zeilen code und nicht eine.

Weis nicht obs das für den vc compiler auch gibt, aber du kannst bei gcc afaik profile guided optimization machen, d.h. du baust es einmal mit -p glaub, lässt es laufen und sagst ihm dann er soll die profiling daten nehmen um das zu optimieren. Bringt aber imo auch nur bedingt was und ist mit arbeit verbunden. Würd ich jetzt echt nur machen, wenns unbedingt auf Teufel komm raus noch n bisschen schneller sein muss.

Bzgl. Buildgeschwindigkeit: Wenn du inkrementelle builds verwendest, dann solltest du mit kleinen Änderungen eigentlich NIE lange neubauen. Wenn doch, dann hast du entweder mehr includes als du wirklich brauchst oder deine Änderung war nicht klein, weil sie von ganz vielen sourcefiles gesehen wird. Außerdem ist mit parallelen builds mit 2*#CPUs das meiste bauen ziemlich kurz. Selbst ziemlich große Projekte bekommt man da meist in 20-30min hin. Meine eigenen hab ich eigentlich immer mit allen halbwegs bösen optimierungsflags mit komplettem rebuild in unter 10sec gehabt. Ich benutz aber auch gcc4.4 mit 16 buildthreads, keine Ahnung ob die Aussage jetzt hilfreich ist oder nicht. Schade eigentlich, dass es keinen parallelen linker gibt. Müssten sich mal n paar gute Compilerbauer zusammensetzen und das in den gcc reinfrickeln, dann hats n Jahr später jeder.

Du musst halt bedenken, dass du, wenn du von C++ nach amd64 compilierst, aus einer Sprache in eine andere übersetzt, die jetzt nicht mehr so richtig viel miteinander zu tun haben. Außerdem ist das compilieren von C++ afaik nicht entscheidbar, da sowohl das template als auch das makro system Turingmächtig sind, d.h. du kannst programme schreiben, die unendlich lange compiliert werden. In C# compiliert man im großen und ganzen eine Sprache in eine vm Sprache, wobei beide Sprachen gleichzeitig für den selben Zweck entworfen wurden, d.h. der vorgang ist erheblich einfacher. Außerdem ist C# afaik typischerweise als JIT compiliert, das MUSS einfach schnell gehen, sonst isses fürn arsch. Da sagst du du übersetzt das erstmal ein bisschen und schaust dann im run, wie mans optimiert. Das kannst du bei C++ halt nicht (ohne weiteres) machen, weil du sonst einen Compiler miteinbaun müsstest.

Wenn ich das richtig verstanden habe versuchen die llvm Leute das aber für beliebige gcc Sprachen nachzurüsten.(Das Projekt würde das selbst wohl nie so formulieren, aber ich glaub ohne ihr gcc front-end wäre das ding komplett nutzlos, weil einfach kaum ernstzunehmende Projekte drauf bauen würden.)

Jetzt hab ich schon wieder viel zu viel gelabert.

Gruß

EDIT: Parsetime ist fast egal, siehe: http://clang.llvm.org/features.html

EDIT2:

Aber ich mag C++ doch so (bis auf die ganzen Ausnahmen, die es so umständlich machen zu schreiben).

Was für ausnahmen denn?

Macht link time code generation das selbe wie whole & combine? Also einfach den kompletten ast für das projekt erstellen und dann erst code draus machen? Das wäre dann ein sehr nettes feature das man in ein optimized releas build target auslagern könnte, wo man sich dann auch die profile guided optimization gönnt.

Willst du mal den gcc 4.4 port für windows ausprobieren und schauen, ob der bessere Ergebnisse erzielt? Würde mich grad echt interessieren. Wenn ja such mal nach sowas wie tdm gcc.

OT: Wo ist eigentlich die threadübersich hin?

[Psycho]

Naja das Problem ist für nen statischen Compiler nicht entscheidbar.

Ja normal, im Allgemeinen nicht. Aber in vielen üblichen Anwendungsfällen wohl schon. Einmal können Schleifen mit Konstanten ala for(int i=0; i<100; i++) analysiert werden, zum anderen werden, wie Du schon meintest, viele Funktionen wohl nur von einer einzigen Stelle im Programm aufgerufen. Da kann (und sollte imo) der Compiler ja alles inlinen. Gibt bestimmt noch mehr Fälle.

Weis nicht obs das für den vc compiler auch gibt, aber du kannst bei gcc afaik profile guided optimization machen

Ja die Funktion habe ich gestern gefunden, als ich auf der Suche nach dem Profiler war. Aber mir ist es egal wie schnell mein Programm ist, bisher lief es immer schnell genug, die Screenshots waren innerhalb von <10 Sekunden analysiert. Nur wenns jetzt im Debug-Modus ne Minute dauert, ist es natürlich zeitraubend, ständig kleine Änderungen zu testen.

Bzgl. Buildgeschwindigkeit: Wenn du inkrementelle builds verwendest, dann solltest du mit kleinen Änderungen eigentlich NIE lange neubauen.

Ja, dank eurer Tipps geht es jetzt auch erheblich schneller.

Zu LLVM/Clang hab ich mir grad ein paar Beschreibungen durchgelesen. Klingt gut, aber das ganze ist wohl noch relativ neu. Ich möchte ja auch gar nicht meinen Compiler wechseln, bin zufrieden mit Microsoft.

Aber ich mag C++ doch so (bis auf die ganzen Ausnahmen, die es so umständlich machen zu schreiben).

Was für ausnahmen denn?

Hauptsächlich IDE-Feinheiten. Hm vielleicht kenn ich bessere Methoden ja noch nicht, aber wenn ich in Visual Studio ne neue Klasse anlege, erstell ich zuerst die Ordner in der Projektansicht, die dem Namespace entsprechen. Zweimal, für .cpp und .h. Dann drück ich "Neues Teil hinzufügen"->"cpp", geb den Klassennamen an, muss von Hand den Pfad anpassen (redundant). Das gleiche für die Header-Datei. Anschließend kann ich dann lostippern mit namespace bla { class foo { };}

Willst du mal den gcc 4.4 port für windows ausprobieren und schauen, ob der bessere Ergebnisse erzielt?

Nur, wenn der ein Visual-Studio-Addin hat.

[Lord Delvin]

Aber ich mag C++ doch so (bis auf die ganzen Ausnahmen, die es so umständlich machen zu schreiben).

Was für ausnahmen denn?

Hauptsächlich IDE-Feinheiten. Hm vielleicht kenn ich bessere Methoden ja noch nicht, aber wenn ich in Visual Studio ne neue Klasse anlege, erstell ich zuerst die Ordner in der Projektansicht, die dem Namespace entsprechen. Zweimal, für .cpp und .h. Dann drück ich "Neues Teil hinzufügen"->"cpp", geb den Klassennamen an, muss von Hand den Pfad anpassen (redundant). Das gleiche für die Header-Datei. Anschließend kann ich dann lostippern mit namespace bla { class foo { };}

Ich glaube, dass auch VS in der Lage ist mit "neue Klasse" automatisch alles richtig zu machen, ich benutz aber gcc+codeblocks, also bin ich mir da nich so sicher.

Willst du mal den gcc 4.4 port für windows ausprobieren und schauen, ob der bessere Ergebnisse erzielt?

Nur, wenn der ein Visual-Studio-Addin hat.

Glaub ich nicht, obwohl ich mich dunkel an nen Artikel erinner, in dems darum ging den vc compiler durch gcc in VS zu ersetzen.

Ich glaub aber, dass sich das Thema eigentlihc erledigt hat.
Gruß

[Helmut]

@Helmut
Hm, die von mir aufgeführten Tipps haben natürlich auch gerade bezüglich Wartbarkeit der Software echte Vorteile, die man gerade bei größer werdenen Projekten nicht unterschätzen sollte. Gerade entkoppelte Komponenten und der Einsatz von Interfaces ( Stichwort Dependency Injection, hatte ich oben noch nicht aufgeführt ) erhöhen unter anderem auch die Testbarkeit einer Software. Und das Zusammenschmeißen aller Sourcen in ein File erfordert bei jeder noch so kleinen Änderung einen kompletten Rebuild. Aber jedem das seine :).

Gruß Kimmi

Da hast du mich wohl falsch verstanden, ich habe nicht gsagt, dass man alles in eine Datei schreiben soll. Nur kompilieren. Alles, was die Wartbarkeit erleichert, kann man auch machen, wenn man nur eine Datei kompiliert.

Du kannst auch versuchen, eine Cpp Datei zu erstellen, in der du alle deine bisherigen CPP Dateien inkludest.

Ne danke, solche Hacks überlass ich gerne dem Compiler, falls er sie denn anbieten sollte.

Dir ist schon klar, dass der Compiler das nicht kann? Wenn du jede Datei einzeln kompilierst, muss er für jede CPP praktisch fast alle Header parsen. Man könnte schließlich mit dem Präprozessor zwischen den CPPs unterscheiden. Wenn du alles in einer Datei inkludest, wird alles nur einmal geparst.

Ciao

[Psycho]

Dir ist schon klar, dass der Compiler das nicht kann?

Ne, ist mir nicht klar. Wenn ich manuell eine .cpp erstelle, in die #include "a.cpp" und #include "b.cpp" reinkommen und sonst nichts, dann kann das ein Compiler doch implizit automatisch selber machen?
Wenn ich "cl a.cpp b.cpp" aufrufe erwarte ich persönlich nicht a.obj und b.obj, sondern programm.exe. Wie der Compiler das intern rumwurschtelt und was er wo zwischenspeichert, um zukünftige Kompilierungsvorgänge zu beschleunigen, ist mir relativ humpe.

[kimmi]

Wenn man mehrere Files hat und einen Source-Stand mit mehr als 20.000 Lines of Code hat, diese dann alle in ein File merged und das dann allein übersetzt und linkt, weil man eine Zeile Code geändert hat, behaupte ich jetzt einfach mal, daß das höchstwahrscheinlich nicht schneller ist. Zumindest wird das irgendwann einmal eskalieren. Und 20.000 Zeilen sind noch eher wenig. Schließlich hat man nicht ohne Grund angefangen, das zu separieren.

Gruß Kimmi

[Helmut]

Es ist aber nich das selbe, wenn du cl a.cpp b.cpp machst, oder wenn du beide Dateien in einer inkludierst und diese dann kompilierst.
Sämtliche Definitionen werden für jede Datei beim Kompilieren gelöscht, d.h., dass auch die Definitionen für die Includeguards für jede cpp gelöscht werden. Es müssen also normalerweise die selben Header wieder und wieder geparst werden. Das ist ja der Hauptgrund (außer Templates vielleicht), warum das Kompilieren in C++ so lange dauert.
Wenn du alles in einer Datei inkludest, wird wegen der Includeguards dann auch tatsächlich jede Datei nur einmal geparst. Die Reihenfolge der Cpps kann dann natürlich eine Rolle spielen. Globale Variablen in einer Datei definiert, können dann in anderen ohne extern sichtbar werden. Das würde ich aber eher als Vorteil sehen:)

Ciao

[Helmut]

Das oben war an Psycho gerichtet ;)

@Kimmi
Ja falls man nur was in einer CPP ändert ist die Methode nicht vorteilhaft. Es kommt aber auch nicht selten vor, dass man etwas an einer häufig veränderten Headerdatei ändern möchte, und dann holt man sich die Zeit denke ich locker zurück.

[kimmi]

Hm, wir sehen das wahrscheinlich aus verschiedenen Sichten. Ich muß hier sehr oft nur eine Zeile Coed ändern. Bei deinem Vorschlag würde ich dann viel viel viel warten :).

Gruß Kimmi

[Krishty]

(Ich habe da ein Bild von den Leuten im Kopf, die ihre Shader als C-Strings hardcoden und ihre Programme 200 Mal kompilieren, statt die Shader in Textdateien auszulagern.)

MessageBox(0,L"me was executed",0,0);
Na und?

Das war anders gemeint. Wenn der Text „me was executed“ sich nie mehr ändert, gut. Wenn du dein Programm aber 200 Mal kompilieren musst um Textbreite, -Ausrichtung und Erscheinung unter allen möglichen Umständen zu korrigieren und zu perfektionieren (wie bei besagten Shadern, wo die Syntaxprüfung erst zur Laufzeit erfolgt und man für jede Korrektur und jede Feinabstimmung den String verändern muss), dann darfst du dich auch nicht über die Kompilierzeit wundern, weil es ausgelagert gehört.