lange Kompilierzeiten
-
Ich habe ein Problem mit dem Builder 5.0. Leider habe ich keine Möglichkeit das Programm auf den 6er zu portieren...
Auf jeden Fall gehen mir die Kompilierzeiten ganz schön auf den Keks!
Das Programm ist mitlerweile einige millionen Quelltextzeilen schwer...und fast jedesmal wenn ich einen Veränderung vornehme kompiliert er nochmal alles komplett, was schonmal 5 Minuten dauern kann
Komischerweise rafft er es wenn ich nur an einer Datei was ändere, dann kompiliert er auch nur diese. Aber sobald ich zweie ändere macht er wieder einen "compile all"...Weiss Jemand Rat???
Hab in den Compiler-Einstellungen leider nix finden können...
-
sTormtrOOpa schrieb:
Auf jeden Fall gehen mir die Kompilierzeiten ganz schön auf den Keks!
Das Programm ist mitlerweile einige millionen Quelltextzeilen schwer...und fast jedesmal wenn ich einen Veränderung vornehme kompiliert er nochmal alles komplett, was schonmal 5 Minuten dauern kann
Komischerweise rafft er es wenn ich nur an einer Datei was ändere, dann kompiliert er auch nur diese. Aber sobald ich zweie ändere macht er wieder einen "compile all"...Weiss Jemand Rat???
Auf Delphi umsteigen...
Nee im ernst, die langen Compilierzeiten sind sicher einer der Nachteile von C++. Du kannst aber mit ALT+F9 explizit nur die aktuelle Unit compilieren. Das sollte Zeit sparen falls du das Programm nicht starten, sondern nur eine Syntaxprüfung der aktuellen Unit haben willst.
Gruß
Martin
-
Man kann Header als Pre-Compiled einbinden. Dann werden die nur mitkompeliert, wenn man auf Projekt/Projekt neu erstellen klickt.
Siehe auch:
http://www.bcbdev.com/articles/pch.htm
Nee im ernst, die langen Compilierzeiten sind sicher einer der Nachteile von C++.
wie kannst du Compilerzeiten auf eine Sprache abschieben? Das hat doch nun wirklich nichts damit zu tun. Das liegt eher daran, das Borland da halt nicht optimiert hat. Der Compiler und der Linker bei Borland sind halt langsammer als andere Compiler der selben Sprache.
-
AndreasW schrieb:
wie kannst du Compilerzeiten auf eine Sprache abschieben? Das hat doch nun wirklich nichts damit zu tun. Das liegt eher daran, das Borland da halt nicht optimiert hat. Der Compiler und der Linker bei Borland sind halt langsammer als andere Compiler der selben Sprache.
Mir hat mal jemnad erzählt, dass auf Grund der Includerei der Compilieraufwand von C++ in etwa O(n^2) entspricht. Das läge daran, dass C++ gegenüber einer modernen Sprache wir Delphi viele "Altlasten" mit sich rumträgt. Ob er damit Recht hatte, dafür kann ich die Hand nicht ins Feuer legen. Aber dass Der Compilieraufwand eine Eigenschaft der Sprache darstellen kann finde ich dagegen schon einleuchtend. Ist der Microsoft Compiler denn wirklich schneller? (Den kenne ich nicht) Ich meine damit nicht nur ein bisschen schneller, sondern ob er eine ganz anderes Verhalten des Aufwandes mit zunehmender Quelltextcomplexität zeigt. Ich lasse mich gerne eines besseren belehren... Vielleicht finde ich ja auch was im WWW, werde mal suchen...
Gruß
Martin
-
Nach meinen Erfahrungen muß der Compiler immer dann viel neu übersetzten, wenn man in den H-Dateien etwas abändert. Dann müssen nämlich sämtliche Dateíen, die die entsprechende h-Datei includen, neu übersetzt werden, und das kostet leider viel Zeit.
Änderungen in den cpp-Dateien bewirken nur eine Übersetzung der aktuellen cpp-Datei.
-
martin_b schrieb:
Mir hat mal jemnad erzählt, dass auf Grund der Includerei der Compilieraufwand von C++ in etwa O(n^2) entspricht. Das läge daran, dass C++ gegenüber einer modernen Sprache wir Delphi viele "Altlasten" mit sich rumträgt. Ob er damit Recht hatte, dafür kann ich die Hand nicht ins Feuer legen.
dsa würd ich auch nicht tun. Die Begründung ist so falsch wies gerade mal geht. In anderen Sprachen werden auch Header eingebunden. das wird nur anders bezeichnet (include, uses, using....). Sicherlich wird vom Compiler eine Sprache übersetzt und ist deshalb Sprachabhängig. Aber die Compilerzeiten des BCBs stehen in keinen Verhältnis zu anderen Compilern.
Natürlich hängt die Compilierzeit von der Anzahl der Dateien, die Compiliert werden sollen, ab. Das ist aber überall so und nicht C++- Spezifisch.
martin_b schrieb:
Ist der Microsoft Compiler denn wirklich schneller?
Oh ja. Gewaltig schneller. Aber nicht nur der MS.
-
vielen dank für die tipps! werde es dann mal ausprobieren...
ich habe ein ähnliches projekt auch schon mit visual c++ 6.0 erstellt, da ist die Kompilierzeit um den Faktor 10-100 schneller!!!
Borland 5 ist halt einfach noch nicht so ausgereift denke ich...
-
Hi,
ich wollte trotzdem noch meinen Senf zu dem Thema abgeben.
Das CBuilder-Projekt, an dem ich gerade arbeite, umfaßt gut 100000 Zeilen (selbst geschriebenen) Quellcode und eine komplette Neuerstellung der Anwendung dauert ca. 183 s (AMD Mobile Athlon XP 2400+).
Den Wert konnte ich allerdings erst nach einer Umstrukturierung meines Quellcodes erreichen. Bis dato hatte das ca. 10 Minuten gedauert.
Die Ursache waren, wie von Burkhi schon angesprochen, die vielfältigen Abhängigkeiten, die durch das inkludieren von .h-Dateien entstehen. Diese Abhängikeiten waren in meinem Fall eindeutig auf Schwächen in der Architektur zurückzuführen.Ein Beispiel:
Wenn ein Formular auf eine Tabelle zugreift, die in einem Datenmodul liegt, schafft man durch ein Inkludieren der Datenmodul-Header-Datei eine oftmals unnötige Abhängigkeit. Jedesmal, wenn am Datenmodul etwas geändert wird, das zu einer Änderung der Header-Datei führt, muß auch das Formular neu übersetzt werden. Gleiches gilt für alle anderen Formulare, die diese Datei inkludieren.
Wenn es möglich ist, sollte das Tabellen-Objekt in diesem Fall nur über einen Zeiger dem Formular übergeben werden. Mehr muß das Formular einfach nicht wissen.
-
AndreasW schrieb:
martin_b schrieb:
Ist der Microsoft Compiler denn wirklich schneller?
Oh ja. Gewaltig schneller. Aber nicht nur der MS.
Du vergleichst hier aber nicht Äpfel mit Birnen, also z.B. das Kompilieren eines VCL-Projektes im BCB mit dem Kompilieren einer reinen WinAPI- oder Standard-C++-Anwendung im VC++, oder!?
-
Hi Jansen
das ist meiner Meinung nach durchaus vergleichbar.
BCB -> VCL -> Anwendung -> exe
VC++ -> MFC -> Anwendung -> exewo ist da der unterschied ?
-Keiner von beiden muss das Framework kompilieren.
-Beide sind C++
-beide haben ein Framework drauf
-und beide erstellen eine Anwendung.
-
Eins ist sicher, von dir würde ich kein Obst kaufen!
Für mich ist eine Aussage wie "Compiler A ist langsamer als Compiler B" nur dann zulässig, wenn der Vergleich unter möglichst identischen Vorraussetzungen durchgeführt wird, d.h. z.B. die gleichen Header zu verwenden.
-
Hallo,
ich finde diesen Thread lustig, nicht böse sein. Also, der Borland- Compiler ist langsamer und erzeugt auch schlechteren Code, das ist kein Geheimnis. Bedauerlich aber wahr, und deshalb steige ich trotzdem nicht auf den Microsoft- Compiler um, sondern halte dem "eingestaubten" die Treue. Es ist auch kein Problem. Wir haben Projekte, da dauert die Compilierung bis zu einer Stunde, aber wann compiliert man das ganze Projekt? Ach so dschensky, 100.000 selbstgeschriebene Zeilen, 183s, ist das eine Supercomputer der NASA? Oder hast Du das "Zeilen zählen" dem Compiler überlassen, und die Windows + vcl- Headerdateien mitgezählt? Außerdem hat der Borland- Compiler viele andere Vorteile, die in der Sprache und den Möglichkeiten liegen. Und noch etwas, Delphi ist als Sprache übrigens nicht wesentlich jünger als C++, es basiert ja auf dem alten Pascal und schleppt deren "Altlasten" mit sich herum. Es ist ebenso wie C++ ein Hyprid, und hat zudem im Laufe der letzten Jahre viele Eigenschaften von C++ (oder C) übernommen. Da sollte man wirklich nicht Äpfel mit Birnen vergleichen. Die Ursache für die langen Compilier- und Linkzeiten liegen in dem komplexeren Modell der Sprache und den Möglichkeiten, die C++ (und auch schon C in der strukturierten Programmierung) dem Entwickler geben, und lieber spare ich viel Zeit in der echten Entwicklung und beim Kodieren, und lasse den PC etwas länger compilieren, bzw. ich habe dann ein schnelleres Programm. Aber das ist sicherlich auch Ansichtsache. Aber eines stimmt, reine VCL- Programme, die sich 1 : 1 nach Delphi übersetzen lassen, sollte man besser in Delphi schreiben.Und Jansen hat recht, man kann die VCL und die MFC nicht miteinander vergleichen. Die Herleitung framework -> Anwendung -> exe stimmt so nicht. Es sind beides Frameworks, ja, aber die VCL ist auf einem höheren abstrakten Niveau angesiedelt. Dadurch ist sie leichter einzusetzen (man kann schneller damit Resultate erzeugen), was aber wiederum in der Codegröße, der Ausführungszeit und eben der Compilierzeit zu merken ist. Wenn man reine Konsolenprogramme übersetzt, dann ist der Borland- Compiler nicht so viel langsamer. Und achso, als ich das erste Mini- Programm mit "managed c++" und .net compiliert habe, da war der Microsoft- Compiler total langsam beim übersetzen, da konnte man bei "Hallo Welt" Kaffee kochen. Aber das ist dann ja eine Veränderung zu einer modernen Sprache.
Ich hoffe, ihr nehmt diesen Thread selber nicht zu ernst. Aber es ist ja Freitagnacht. Ich wünsche Euch ein schönes Wochenende
Volker
-
Volker,
VolkerH schrieb:
Ach so dschensky, 100.000 selbstgeschriebene Zeilen, 183s, ist das eine Supercomputer der NASA? Oder hast Du das "Zeilen zählen" dem Compiler überlassen, und die Windows + vcl- Headerdateien mitgezählt?
ich hatte gehofft, durch den Zusatz "selbst geschriebenen" alle eventuell auftretenden Unklarheiten ausräumen zu können. Und was das Zeilen-zählen betrifft: dafür habe ich ein räudiges Progrämmchen geschrieben, welches das für mich übernimmt. Leerzeilen wurden bereits abgezogen. Wenn ich noch alle Kommentare ignoriere, lande ich vermutlich irgendwo bei 95.000 Zeilen.
Da Du meine Angaben aber trotzdem irgendwie zu bezweifeln scheinst, habe ich nochmal gezählt und Stichproben gemacht, ob tatsächlich richtig gezählt wird.
Mit "komplette Neuerstellung" meine ich den Eintrag "Build {Projekt-Name}" im Menü "Project" - nur für den Fall, daß wir von verschiedenen Sachen sprechen. Das habe ich nochmal gemacht und komme jetzt auf 189s - keine Ahnung, warum das variiert.
Ich entwickle mit dem CB4 - vielleicht spielt das eine Rolle.Ansonsten habe ich wirklich keinen Grund, mir hier irgend welche utopischen Werte aus den Fingern zu saugen ...
-
100.000 Zeilen Code. Mensch, das ist eine ganze Menge. Was solln das für ein Programm sein? Earth Simulator?
Nein, mal im Ernst. Eh ein Heim-Entwickler auf solch riesige Programme kommt braucht er 1-2 Jahre Entwicklungszeit.
Dann haste die ganzen Zeilen noch umgeschrieben. Wenn du dich um eine Null vertan hast, wird die Sache schon eher glaubwürdiger.
-
Hallo dschensky,
jetzt machst Du mich neugierig. Ich habe hier einige Projekte, die sind zwar etwas größer (aber da schreibt auch nicht einer alleine dran, und es sind dll's dabei, die wieder in anderen Projekten auftauchen, und wir zählen die Leerzeilen mit), da brauchen wir beim Übersetzen zwischen 30 und 60 Minuten, und unsere Rechner sind auch nicht so schlecht. Das ist bei großen Projekten auch durchaus normal, insbesondere wenn die VCL im Spiel ist. Und da wird die komplette Neuerstellung wirklich zu einem Kraftakt. Ich habe mir mal den Spass gemacht, auf einer 8- Prozessor Hochleistungsmaschine mit SAN, 2 Plattenprozessoren und 2GByte Cache für den Platten einen BCB5 zu installieren und ein Projekt mit ca. 120.000 Quelltextzeilen zu erzeugen, und auch dass hat bestimmt 10min gedauert, also kann es nicht am Rechner liegen, dass ist hier denke ich auch allen klar. Bei dieser Zeilenanzahl sind das schätzungsweise zwischen 3 und 4 MByte Quelltext, die da verarbeitet werden müssen. Also, was ist das für ein Projekt, in dem sich 100.000 (ohne Leerzeilen) in 3 min übersetzen lassen? Ich habe schon viel erlebt, aber das macht mich sprachlos, da bin ich wirklich neugierig.Schöne Grüße auc Berlin
Volker
-
Hedgehog,
Hedgehog schrieb:
Was solln das für ein Programm sein? Earth Simulator?
Nein, mal im Ernst. Eh ein Heim-Entwickler auf solch riesige Programme kommt braucht er 1-2 Jahre Entwicklungszeit.mir ist nicht ganz klar, was Du sagen willst. Tut mir leid, wenn die Zahl 100.000 Deine Vorstellungskraft übersteigt, aber das ist durchaus kein unüblicher Wert. Und ja, die Entwicklungszeit beträgt bis jetzt ca. 1.5 bis 2 Jahre.
"Heim-Entwickler" klingt irgendwie abfällig bei Dir. Aber ich kann Dich beruhigen, es ist kein Heim-Projekt.Hdgehog schrieb:
Dann haste die ganzen Zeilen noch umgeschrieben.
Verstehe ich nicht. Was meinst Du damit?
VolkerH schrieb:
Also, was ist das für ein Projekt, in dem sich 100.000 (ohne Leerzeilen) in 3 min übersetzen lassen?
Es ist eine Anwendung mit viel Datenbank-Quellcode (TDataSet) - eigentlich nichts besonderes. Sie basiert nur auf der VCL, abgesehen von ein wenig WinAPI. Keine STL.
Eine Besonderheit ist vielleicht noch, daß viele Formulare Teil einer eigenen Vererbungs-Hierarchie sind. Allerdings wüßte ich nicht, warum das die Compilier-Zeit verkürzen sollte.
Wenn ich wüßte, was beim Compilieren i.allg. die meiste Zeit in Anspruch nimmt, könnte ich vermutlich genauer Auskunft geben.Ich habe meinen Zeilen-Zähler noch um die Erkennung einfacher Kommentare (//) erweitert. Jetzt lande ich bei gut 90.000 Zeilen. Die Größenordnung stimmt aber noch. Ich habe das Programm mal hier hochgeladen - aber wie gesagt, es ist ein räudiges Teil ... (und vielleicht zählt es ja sogar falsch - glaube ich aber nicht
)Die Anwendung heißt im übrigen "ISMAN". Ein paar (ältere) Screen-Shots sind auf der Site meiner Firma zu sehen.
-
Hallo dschensky,
ich habe mir Dein Tool mal angesehen. Soweit eigentlich ganz gut, aber es gab doch Abweichungen, die ich mir mal näher angesehen habe. Es hat etwas gedauert und vielleicht bin ich ja altmodisch, ich zähle dfm, bpr und ähnliche Dateien quantitativ nicht zum Quelltext. Hier wird tatsächlich schnell sehr viel Quelltext erzeugt (den man übrigens auch nicht selber geschrieben hat), der auch nicht vom Compiler übersetzt wird. Es ist also interessant, dass Du sie in diesem Zusammenhang mitzählst. Ich habe mal ein Teilprojekt, dass VCL- lastig ist, genommen, und ausgewertet.
Ich habe 42 Quelldateien mit 8.954 Zeilen, Du kommst durch Dein Programm auf 63 Dateien mit 24.743 Zeilen. Koorigiere Dein Programm dahingehend, dass Du Ressourcendateien entfernst, die nichts mit C++ zu tun haben. Und dann können wir unsere Zahlen und Ergebnisse wieder vergleichen.
Schöne Grüße aus Berlin
Volker
-
Hi VolkerH.
Mach das Tool mal nicht so schlecht!
Wenn bei Dir ALLE Dateien gezaehlt werden (.bpr, .dfm ...), liegt das daran, dass Du wahrscheinlich keine Filter angegeben hast!
Bei mir zaehlt das Tool genausoviel (wenig!) Zeilen wie mein eigener WC!
-
Volker,
VolkerH schrieb:
und vielleicht bin ich ja altmodisch, ich zähle dfm, bpr und ähnliche Dateien quantitativ nicht zum Quelltext.
das hätte ich vielleicht dazu sagen sollen: Wenn Du in der linken Liste eines der Verzeichnisse auswählst, auf die sich Dein Projekt verteilt, kannst Du auf der rechten über den Schalter "Add" einzelne Datei-Masken hinzufügen. Dann wird in diesem Verzeichnis auch nur nach den betreffenden Dateien gesucht. Ohne die Angabe von Datei-Masken sucht das Programm nach ..
Natürlich habe ich in meine Zählung nur *.cpp und *.h einbezogen.
-
Hi.
Ich wollte noch ein paar Infos loswerden.
- Ich habe ein paar cpp- und h-Leichen in meinem Projekt-Pfad übersehen. Die sind jetzt aber garantiert alle weg.
- Der Zeilen-Zähler zählt jetzt auch die mehrzeiligen Kommentare mit (/* ...*/).
Jetzt komme ich auf gut 71.000 echte Code-Zeilen.
-
Ein wichtiger Faktor bei der Compilier-Zeit scheinen die Abhängigkeiten zwischen den Modulen/Klassen abzugeben. Ich habe das ganze Projekt nach sinnlosen #include-Anweisungen durchforstet und diese entfernt bzw. geändert.
Z.B. solche: B inkludiert A und C inkludiert B, weil C etwas aus A benötigt. ==> geändert zu: C inkludiert A (und nicht
Das hat nochmal eine Verminderung der Compilierzeit um ca. 30 s gebracht. -
Die Compilier-Zeit muß auch durch irgendwelche Cache-Geschichten beeinflußt werden.
Hier meine neuen Werte:
174 s (nach komplettem Windows-Neustart)
133 s (unmittelbar danach, ohne den CBuilder neu zu starten)
146 s (danach, mit 3 modifizierten cpp-Dateien)Eigentlich sollte zwischen den Werten 2 und 3 kein signifikanter Unterschied bestehen, hätte ich gedacht.
