lange Kompilierzeiten

sTormtrOOpa

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...

dschensky

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.

Jansen

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!?

AndreasW

Hi Jansen

das ist meiner Meinung nach durchaus vergleichbar.

BCB -> VCL -> Anwendung -> exe
VC++ -> MFC -> Anwendung -> exe

wo ist da der unterschied ?

-Keiner von beiden muss das Framework kompilieren.
-Beide sind C++
-beide haben ein Framework drauf
-und beide erstellen eine Anwendung.

Jansen

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.

VolkerH

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

dschensky

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.

VolkerH

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

dschensky

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.

VolkerH

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

DerAltenburger

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!

dschensky

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.

dschensky

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.

Fox-Alpha

Hallo,
wollte mich mal zu dem Theme melden.

Ich habe bemerkt das sich der Compiler anders verhält wenn delphi sprich *.pas Dateien mit eingebunden werden.

Beispiel :
Ich verwende für mein Programm eine modifizierte comctrls.pas um eine Kompatibilität zum XPTheme zu haben (Stichwort Listview) Steht auch in der FAQ.

Wenn ich die PAS also im Projekt drinne habe Compiliert der jedesmal den kompletten Source neu, egal ob ich ein Zeichen oder eine meherer Dateien verändert habe.

Für die dauer der Entwicklung nehme ich also diese heraus um eine angenehmere Compilerzeit zu haben. Mein Projekt hat zwar keine 70K Zeilen ist aber dennoch relativ gross.

Ich hatte auch hier im Forum schonmal nach einer Lösung gefragt und sämtliche möglichkeiten in den Optionen probiert hat aber nichts gebracht bzw. habe keine Antwort darauf erhalten.