Kompilieren durch RAM-Disk beschleunigen?
-
Hallo,
bei meinem Projekt schreibt Visual C++ bei einem kompletten Kompiliervorgang ca. 32 MB Objektdateien in ca. 100 verschiedenen Dateien in den Ausgabeordner.
Könnte man den Vorgang beschleunigen, indem man den Ausgabeordner auf eine RAM-Disk verlegt? (vorausgesetzt die Festplatte ist der Flaschenhals - aber besser für die Platte dürfte es ja allemal sein)Hat jemand von euch das schonmal gemacht und Verbesserungen bemerkt?
Danke!
-
Glaube kaum, dass beim kompilieren I/O der Flaschenhals ist
Probiers doch einfach aus.
-
TomasRiker schrieb:
Hallo,
bei meinem Projekt schreibt Visual C++ bei einem kompletten Kompiliervorgang ca. 32 MB Objektdateien in ca. 100 verschiedenen Dateien in den Ausgabeordner.
Könnte man den Vorgang beschleunigen, indem man den Ausgabeordner auf eine RAM-Disk verlegt? (vorausgesetzt die Festplatte ist der Flaschenhals - aber besser für die Platte dürfte es ja allemal sein)Hat jemand von euch das schonmal gemacht und Verbesserungen bemerkt?
Danke!
Also der gcc hat eine Option namens "-pipe", die soweit ich weiß genau dieses Problem angeht (in dem halt Pipes statt Dateien für den Transport zwischen den verschiedenen Stufen benutzt werden). Vielleicht hat der Visual C++ Compiler auch sowas?!
-
.filmor schrieb:
TomasRiker schrieb:
Hallo,
bei meinem Projekt schreibt Visual C++ bei einem kompletten Kompiliervorgang ca. 32 MB Objektdateien in ca. 100 verschiedenen Dateien in den Ausgabeordner.
Könnte man den Vorgang beschleunigen, indem man den Ausgabeordner auf eine RAM-Disk verlegt? (vorausgesetzt die Festplatte ist der Flaschenhals - aber besser für die Platte dürfte es ja allemal sein)Hat jemand von euch das schonmal gemacht und Verbesserungen bemerkt?
Danke!
Also der gcc hat eine Option namens "-pipe", die soweit ich weiß genau dieses Problem angeht (in dem halt Pipes statt Dateien für den Transport zwischen den verschiedenen Stufen benutzt werden). Vielleicht hat der Visual C++ Compiler auch sowas?!
die objektdatei ist auch beim gcc das finale produkt des kompilierens, -pipe hilft da nicht. ich bezweifle auch, dass I/O-performance beim kompilieren das problem ist (beim linken könnte es allerdings evtl. helfen). wichtiger ist, den compiler nicht die selben sachen mehrfach machen zu lassen, die geschickte verwendung eines vorkompilierten headers ist bei großen projekten im grunde ein muss.
-
Das Problem ist doch die Kopmpilierstrategie. Rechenleistung ist heute ohne Ende da, komischerweise wird das Kompilieren nie schneller. Ich muß immer warten. D.h. das Kompilierkonzept muß hier geändert werden. Und da hat sowohl MS was in Arbeit für die nächsten Compiler-Versionen (oder war das schon im 2005er?), wo man z.B. mehrere Projekte gleichzeitig builden kann.
Oder man nimmt Incredibuild. Dieses Plugin für VC++ kompiliert nach einer anderen Strategie: http://www.xoreax.com Gibts auch eine 30 Tage-Testversion.
Eine Möglichkeit wäre, das kompiliert wird, während ich mich noch im Editor befinde und "nachdenke". Warum erst dann kompilieren, wenn ich es anstosse? Machen Java-IDEs auch nicht.
-
Bringt das Incredi-Build etwas wenn man nur einen PC hat?
-
Artchi schrieb:
Das Problem ist doch die Kopmpilierstrategie. Rechenleistung ist heute ohne Ende da, komischerweise wird das Kompilieren nie schneller.
Wenn du das behauptest, dann hast du noch nie nebeneinander ein Gentoo auf einem P2-233 und einem Athlon64 aufgesetzt ;).
Dr. Prof schrieb:
Bringt das Incredi-Build etwas wenn man nur einen PC hat?
Wenns sowas wie distcc ist kaum.
-
Wenn man ein ganzes OS buildet, kann ich mir schon vorstellen, das sich am ENDE die Leistung bemerkt macht.
Aber täglich mach ich das: ich kompilieren nur wenige geänderte Dateien. Und komischerweise bewegt sich das immer im Bereich von mehreren Sekunden. Das war auf meinem P90 so, und ist auf meinem Athlon64 immer noch so. Wenn du verstehst, was ich meine?
-
hm... ich kompilier auf einem P3 (oder 2?) mit 600 MHz und 128 MB Ram... Dauert so ca. 15 min bis er das ganze Projekt übersetzt hat. DAS ist langsam
-
Ja, ein ganzes Projekt ist ja auch was anderes (siehe OS-Beispiel). Aber ein ganzes Projekt baut man auch nicht alle paar Minuten immer wieder neu.
-
genug speicher vorausgesetzt, liegen die ganzeh headers eh im cache und die ganzen ausgaben wern bloß in den cache geschrieben und später, wenn der rechner zeit hat, nebenbei geschrieben. theoretisch also null gewinn duch ramdisk.
wenn wenig speicher da ist, sogar verlust, wenn er bei jedem compiliervorgang was auf das swapfile auslagern muss, statt objektdateien, die er erstmal lange nicht braucht.
theoretisch ist aber das ramdisk-filesystem trivialer und deshalb wieder ein wenig schneller.
unter dos hab ich mit ner ramdisk enorm beschleunigt. unter win98 noch ein wenig. unter xp ist es mir nicht mehr gelungen. unter linux benutze ich die ramdisk, damit bei parallelem compilieren auf der platte nix fragmentiert. ka, ob's was bringt, aber es macht spaß.
-
volkard schrieb:
unter linux benutze ich die ramdisk, damit bei parallelem compilieren auf der platte nix fragmentiert.
ich dachte immer das Linuxtypische Dateisysteme (Ext, Reiser) nicht (oder kaum) defragmentiert werden können?
Wenn man ne große Ramdisk hat, dann kann man ja die Swapfile auch auf dieser auslagern
-
Dieser Thread wurde von Moderator/in kingruedi aus dem Forum Rund um die Programmierung in das Forum Compiler-Forum verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.