Visual Studio 2005 Linking brauch 20min., geht es kürzer?
-
Hallo,
ich arbeite in einem Projekt mit ca. 1000000 Zeilen Code und tausenden von Klassen.
Momentan arbeite ich gerade an einer zentralen Klasse die fast alle Includieren.
Jedesmal wenn ich kurz etwas ausprobiern will z.B. aus i+=1; ein i+=2 machen, fragt mich visual Studio danach:
This project is out of date!
projXYZ
Would you like to build it?
Yes No ChancelDrücke ich Yes, kann ich danach 20min warten weil er anfängt zu linken.
Nun meine Frage was passiert wenn ich No drücke?
Ich nehm mal an das meine änderungne dann nicht in der Binary stehen, oder?Hat jemand sonst nen tipp wie ich das Beschleunigen kann.
Gruss
Grim
-
Ich habe keine Erfahrungen mit so großen Projekten, kann daher nur spekulieren:
Dauert wirklich das Linken so lange, oder ist es das erneute Kompilieren der ganzen Klassen, welche diese datei mit include einbeziehen?
(Das linken ist dass, welches ganz zum schluss alles "zusammenfast")
Wenn es das erneute kompilieren der ganzen Klassen ist, dann hast du Änderungen in der Headerdatei vorgenommen. Aber etwas wie i+=1 sollte normalerweise genau deshalb nicht in der Headerdatei, sondern in der cpp Datei zu finden sein.
Wenn wirklich das Linken so lange dauern sollte, dann könnte man aus dieser Datei eine DLL erstellen lassen (wenigsten so lange daran garabeitet wird)
Bei Änderungen in der cpp würde nur diese DLL erstellt werden und er müsste nicht das gesammte Programm neu linken. Anschließend link er beim Starten des Programms die geänderte DLL dynamisch ins Programm ein.Das setzt aber immer noch voraus, dass die Headerdatei nicht verändert wird! Ansonsten wird er den rest wieder erneut kompilieren und linken müssen!
-
grim schrieb:
Would you like to build it?
Yes No ChancelNun meine Frage was passiert wenn ich No drücke?
Ich nehm mal an das meine änderungne dann nicht in der Binary stehen, oder?Bingo!
Hat jemand sonst nen tipp wie ich das Beschleunigen kann.
Idealerweise nur in den Einstellungen für Debug:
* Link-Time-Code-Generation abdrehen
* Incremental Linking aufdrehenUnd natürlich: Den Code in mehrere DLLs aufsplitten würde vermutlich am meisten Bringen.
-
Wenn du an den Header-Dateien nichts änderst, könntest du auch precompiled Headers nehmen, sprich vorkompilierte Header, kannste im Visual Studio einstellen.
Allerdings nur dann wenn das kompilieren so lange dauert.Lg freeG
-
Das einfachste wäre es wohl solche Variablen aus Dateien zu lesen, damit man nicht ständig neu bauen muss, wenn man mit den Ergebnissen rumexperementieren möchte.
Ansonsten muss das bei 20min ja echt ein Monsterprojekt sein..
Aber wie schon genannt:
Incremental Linking anschalten und eventuell vorkompilierte Header verwenden, das senkt auch die Kompilierzeit extremst.
rya.
-
Dieser Thread wurde von Moderator/in evilissimo aus dem Forum C++ in das Forum MFC (Visual C++) verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Ja, verwende Precompiled Header...
-
Verwendest Du "Whole program optimization" und "Link Time Code Generation"?
Dann wundert es micht nicht. Denn dann läuft der eigentliche Compile und Optimierungsvorgang erst während des Linkens...
-
z.T. PCH... seit wann bringt das denn was beim Linken?
Falls natürlich der OP sich ungenau ausgedrückt hat, und eigentlich die Compile + Link Zeit meint, dann ... ist PCH natürlich ein guter Tip (ist bei den meisten vonunseren Projekten sicher > Faktor 5 um)
-
Wie wäre es wenn du den magischen Visual-Studio-Schalter benutzt und mit mehreren Kernen parallel kompilierst.
Skaliert wunderbar, sollte dann in 5min zu schaffen sein.
-
nurf schrieb:
Wie wäre es wenn du den magischen Visual-Studio-Schalter benutzt und mit mehreren Kernen parallel kompilierst.
Skaliert wunderbar, sollte dann in 5min zu schaffen sein.Das nützt für das Optimiren des Linkens == 0.
Der OP fragte nicht nach dem kompilieren sondern dem linken...
-
Am sinnvollsten wäre es, zum eben-mal-ausprobieren Debug-Builds zu benutzen. Die laufen nicht so fix, sind aber schnell zusammengestellt und zum Debuggen eh besser geeignet. Eigentlich ist das so gedacht, dass man Release-Builds nur fürs Release baut.
Falls etwas dagegen spricht, kannst du ja wenigstens eine weitere Projektmappenkonfiguration einführen, die sich wie Release ohne Linkzeitoptimierung verhält und die zum Ausprobieren benutzen.