Wie lang kompiliert (und linkt) ihr?

Dravere

byto schrieb:

Besser gut dokumentierter, wartbarer Code, der 10x so lang ist, als irgendwelche kongenialen und komplizierten Wegwerf-Einzeiler.

Redest du gerade davon, dass Java gut dokumentierbar und wartbarer Code hat? Ich wechsle jedes grössere Projekt nach C++, weil ich dort bessere Dokumentation und Wartung habe. Schon nur die Deklaration <-> Definition Trennung von C++ ist viel angenehmer zum warten. In Java ist immer alles am Stück, ganz ganz hässlich, meiner Meinung nach.
Aber egal, darum geht es hier ja nicht. Falls ein Diskussionsbedarf und Flamewarbedarf besteht, neuen Thread eröffnen :p

Meine Programme sind immer irgendwo im Bereich von ein paar 10'000 LOC, daher habe ich nicht so lange Compilezeiten. Ausser wenn ich massiver Templateeinsatz habe, was mit der Verwendung von Boost vermehrt vorkommt. Da steigen die Zeiten manchmal auch bei so wenig Code auf ein zwei Minuten.

Grüssli

borg

mh, also ein komplettes rebuild des java projekts an dem ich gerade beruflich arbeite dauert durchaus so 5-10 minuten. (auf einem t30...)

Gregor@Uni schrieb:

Bei mir kompilieren 10.000 Zeilen Javacode (als komplettes Rebuild) in ungefähr einer Sekunde. Und das sollte ungefähr linear mit der Anzahl der Zeilen skalieren. Deshalb ist der Thread hier für Javaprogrammierer "strange". Der Thread adressiert ein Problem, das bei Java überhaupt nicht existiert.

Was macht ein Javacompiler denn? Syntaxcheck und jede Klasse in Bytecode in ne Datei schreiben? Und Bytecode ist doch nur ne andere Codierung für Sourcecode - man bekommt den Source auf jedenfall mal wieder 1:1 aus dem Bytecode mit nem Decompiler.
Und brauchen deswegen Javaporgramme immer so lang zum starten, weil sie just in time kompiliert werden? Also das kompilieren das bei C++ schon viel früher gemacht wird.
Wenn man diese Just in time Compilezeit auch noch dazu rechnet, dann braucht Kompilieren in Java auch länger.

borg schrieb:

mh, also ein komplettes rebuild des java projekts an dem ich gerade beruflich arbeite dauert durchaus so 5-10 minuten. (auf einem t30...)

Generierst du da auch Code (MDA) oder nur kompilieren?

byto

Dravere schrieb:

Ich wechsle jedes grössere Projekt nach C++, weil ich dort bessere Dokumentation und Wartung habe.

Wie groß sind die Projekte dann, dass sich der Aufwand der Portierung für Dich lohnt?

Meine Programme sind immer irgendwo im Bereich von ein paar 10'000 LOC, daher habe ich nicht so lange Compilezeiten.

Aha, winzig.

Dravere schrieb:

Redest du gerade davon, dass Java gut dokumentierbar und wartbarer Code hat? Ich wechsle jedes grössere Projekt nach C++, weil ich dort bessere Dokumentation und Wartung habe. Schon nur die Deklaration <-> Definition Trennung von C++ ist viel angenehmer zum warten. In Java ist immer alles am Stück, ganz ganz hässlich, meiner Meinung nach.

Meine Programme sind immer irgendwo im Bereich von ein paar 10'000 LOC, daher habe ich nicht so lange Compilezeiten.

Was ist der Vorteil immer Deklaration und Definition ändern zu müssen, statt nur eines?

Dravere schrieb:

Ich wechsle jedes grössere Projekt nach C++, weil ich dort bessere Dokumentation und Wartung habe.

das sollte jetzt ein witz sein, oder?

EinPaarFragen schrieb:

Wenn man diese Just in time Compilezeit auch noch dazu rechnet, dann braucht Kompilieren in Java auch länger.

Naja nicht wirklich. Jetzt kann man natürlich noch argumentieren, dass der JIT-Compiler nicht so gut optimiert, aber ich habe zum Beispiel gar keine riesigen Unterschiede zwischen Debug- und Release-Build. Der Hauptgrund, warum Java schneller compiliert ist, weil es einfach ein moderneres Übersetzungsmodell hat.

Das textuelle includen von C++ macht es unglaublich langsam, lass dir mal mit ausgeben, was für jede Sourcedatei alles direkt und vor allem indirekt includiert wird... da fallen dir die Augen aus. Je nachdem, wie gut man sein Projekt organisiert, kann man da noch was rausholen, aber C++-Compiler haben einfach viel mehr zu tun.

Ich brauche 12 Minuten für einen kompletten rebuild in der Arbeit, weiß aber nicht, wieviele LOC. Es sind 18 C++-Projekte in so einer Projektmappe von VS.

hustbaer

Hauptgrund, warum Java schneller compiliert ist, weil es einfach ein moderneres Übersetzungsmodell hat

Nö, der Hauptgrund sind Templates. Zumindest bei dem Code den ich schreibe, und ich bin noch LANGE nicht extrem was das angeht.

Das trifft's imho noch nicht ganz. Das Grund ist imho, parsen des Templates -> vector<int> erstellen -> compilieren, parsen des Templates -> vector<float> erstellen -> compilieren, parsen des Templates -> ...

Lass mich kurz nachdenken, welchen immer gleichen Schritt könnte man sich mit einem besseren Übersetzungsmodell sparen? Das geparste Template kann höchstens innerhalb einer Übersetzungseinheit weiterverwendet werden, von tausend, also fast gar nicht. Dad heißt, die Arbeit wird sogar für die gleichen Instanzierungen ständig wiederholt. Wenn das mal keine Unzulänglichkeit im Übersetzungsmodell ist, dann weiß ich's nicht.

hustbaer schrieb:

Hauptgrund, warum Java schneller compiliert ist, weil es einfach ein moderneres Übersetzungsmodell hat

Nö, der Hauptgrund sind Templates.

naja, ich mache nur mit C rum. wenn mich nicht alles täuscht, hab ich noch keinen C-compiler gesehen, der 10000 lines in 1 sekunde schafft (wie gregor es mit java beschrieb ^^). ich nehme an, es liegt auch an optimierungen, die so'n C compiler machen muss, während sich java fast 1:1 in bytecode übersetzen lässt.

Hallo,

mal ne andere Frage, wie ist denn hier die Einheit loc definiert? Wirklich "lines of code" oder sind hier auch die leeren Zeilen und die ganzen File-Headers mit modification history mit dabei...

ach, son swt gedöns kann schonmal richtig lange dauern. also 10 minuten ^^

x schrieb:

mal ne andere Frage, wie ist denn hier die Einheit loc definiert? Wirklich "lines of code" oder sind hier auch die leeren Zeilen und die ganzen File-Headers mit modification history mit dabei...

ich hab' so ein tool ausm internet verwendet. das hat nur code in c-files und aus den headern makros gezählt, die code erzeugen könnten. also keine kommentare, leerzeilen, prototypen und dergleichen. aber stimmt schon, was loc bedeutet, ist nirgends allgemeingültig definiert.

hustbaer

Optimizer schrieb:

Das trifft's imho noch nicht ganz. Das Grund ist imho, parsen des Templates -> vector<int> erstellen -> compilieren, parsen des Templates -> vector<float> erstellen -> compilieren, parsen des Templates -> ...

Lass mich kurz nachdenken, welchen immer gleichen Schritt könnte man sich mit einem besseren Übersetzungsmodell sparen? Das geparste Template kann höchstens innerhalb einer Übersetzungseinheit weiterverwendet werden, von tausend, also fast gar nicht. Dad heißt, die Arbeit wird sogar für die gleichen Instanzierungen ständig wiederholt. Wenn das mal keine Unzulänglichkeit im Übersetzungsmodell ist, dann weiß ich's nicht.

Nope. Solche Templates wie std::vector tun nicht wirklich weh.
Weh tun die Teile wo durch Template-Metaprogrammierung tonnenweise Templateklassen instanziert werden, und das für ein oder zwei Zeilen harmlos aussehendem Programmcode.
Die Regeln bezüglich overload resolution oder auch Regeln wir SFINAE helfen auch nicht gerade die Compilezeiten niedrig zu halten.

Was das Parsen angeht: schonmal von precompiled headers gehört? Funktioniert wunderschön, und hilft das ganze zigfache Parsen zu vermeiden. Bringt bei echten Template-Schlachten aber auch nicht viel, weil das Parsen eben nicht der Teil ist wo wirklich viel Zeit draufgeht. Nicht vergessen: C++ templates sind Turing complete.

Und dann kommt natürlich noch die Zeit dazu die der Optimizer braucht, und das kann auch einiges sein. Ok, hier widerspreche ich mir gerade selbst... aber wenns so is... was soll ich machen
BTW: dass der Optimizer in vielen Programmen SO viel zu tun hat liegt auch oft am "gnadenlosen" Einsatz von Templates. Guck dir mal die Implementierung von Boost.Bind, Boost.Function oder Boost.Lambda an. Huiuiuiui....

p.S.: unterhaltsam ... für die die es noch nicht kennen: http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf

Don06

hustbaer schrieb:

Guck dir mal die Implementierung von Boost.Bind, Boost.Function oder Boost.Lambda an.

Boost.Spirit vergessen?

#include <boost/spirit.hpp>
int main(){}

Dauert bei mir 4-5 Sek.

hustbaer

@Don06:
Jo Spirit und MPL und Multiindex und Typeof und...
Nö, nicht vergessen, aber Spirit und MPL gehören IMO schon zu den abgehobenen Sachen, daher hab ich die mal weggelassen.

Bind, Function und Lambda setze ich fast jeden Tag ein, und die reichen oft schon um Programme schön langsam compilieren zu lassen, daher hab ich die angeführt. Wenn ich sage der "Hauptgrund sind Templates" muss ich ja wohl die angeben die ich wirklich oft verwende, sonst wäre das ja ... geschummelt

auch C++ Programme die wenig bis keine Templates verwenden kompilieren lange.

Dravere schrieb:

Redest du gerade davon, dass Java gut dokumentierbar und wartbarer Code hat? Ich wechsle jedes grössere Projekt nach C++, weil ich dort bessere Dokumentation und Wartung habe. Schon nur die Deklaration <-> Definition Trennung von C++ ist viel angenehmer zum warten.

Klar, als Geschichts- und Informatikstudent hat man da natürlich den Überblick und täglich viele größere Projekte nach C++ zu portieren.

In Java ist immer alles am Stück, ganz ganz hässlich, meiner Meinung nach.

Warte, bis du ins zweite Semester kommst, dann änderst du deine Meinung.

borg

borg schrieb:

mh, also ein komplettes rebuild des java projekts an dem ich gerade beruflich arbeite dauert durchaus so 5-10 minuten. (auf einem t30...)

Generierst du da auch Code (MDA) oder nur kompilieren?

Nur kompilieren. Ein rekursives wc -l im root ordner des projekts sagt 2158214 loc. da sind aber unmengen jsp's, scripte und xml dateien mit drin.
das ist einfach nur abartig für diese "kleine" webanwendung, wenn man bedenkt das der linux kernel mit 9mio loc in der gleichen größenordnung liegt.

byto

Gut dokumentierter Java-Code hat ja schon alleine wegen der Javadoc Kommentare wahrscheinlich um den Faktor 1.5 - 2 mal so viele LOCs. Dazu kommt noch die Tatsache, dass Java-Code häufig durch anonyme Objekte alles andere als kompakt ist (hinsichtlich LOCs).