Compilierzeit zu hoch, was ist falsch?

[AThurm]

Zitat von blackfin:

Allerdings ist das ja der CMD-Compiler..mhm...ich weiss nicht, ob das darauf auch Einfluss hat...

Nein hat es nicht. Ich habe mal alle Warnungen aus Spass deaktiviert, in der IDE liefs dann statt mit 1000 Sekunden in 600 (was immer noch viel zu hoch ist, im Vergleich zu Delphi 7), aber in DOS blieb es bei den 1000s. Ich versuche jetzt auserhalb der Domaine das Projekt zu compilieren, ansonsten fällt mir nichts mehr ein

[himitsu]

Man könnte mal versuchen über die OpenToolAPI sowas wie AQTime in die IDE einzuschleußen.
Eventuell bekommt man da etwas vom Inlinecompiler mit.

Ansonsten bleibt nur noch eine Anfrage im QC oder direkt an den Support.
Hoffentlich kommt dann keine Antwort ala "Kaufen sie XE, denn dort ist ein Bugfix dafür vorhanden".

[dataspider]

Ich hatte etwas in der Art 2 Mal.
Einmal waren für das Debugger - Ereignisprotokoll alle möglichen Meldungen angehakt.
Ein anderes Mal waren es nicht mehr existierende Pfadangaben (ich meine, es war ein Suchpfad in den Projektoptionen).

Frank

[AThurm]

Zitat von himitsu:

Man könnte mal versuchen über die OpenToolAPI sowas wie AQTime in die IDE einzuschleußen.
Eventuell bekommt man da etwas vom Inlinecompiler mit.

Gute Idee, kann ich mal ausprobieren!

Zitat von dataspider:

Ich hatte etwas in der Art 2 Mal.
Einmal waren für das Debugger - Ereignisprotokoll alle möglichen Meldungen angehakt.
Ein anderes Mal waren es nicht mehr existierende Pfadangaben (ich meine, es war ein Suchpfad in den Projektoptionen).

Frank

Das probiere ich mal aus, danke.
Ist es ein Problem für den Compiler wenn die Suchpfade relativ angegeben sind ? (Sie sind nicht "grau" (Existiert also) unterlegt)
Zum Beispiel: ..\source\

[himitsu]

Zitat von AThurm:

Gute Idee, kann ich mal ausprobieren!

Wir hatten jetzt mal das "Problem", dap die IDE-Exceptions (bei Fehlern in der IDE) urplötzlich über EurekaLog liefen.
Der Grund war einfach, daß in einem DesignTimePackage das EurekaLog mit drin war und es sich somit auch in der IDE einnistete.

Package wäre der einfache Weg und über die OTA kommt man eventuell an mehr Infos ran.

An dieser Stelle würde ich relative Pfade weglassen,
denn sie hängen ja vom aktuellen Arbeitsverzeichnis ab und das kann sich schnell mal ändern.

Du kannst aber Variablen nutzen, so wie das $BDS oder $(BDS), wobei man dort alles aus den Umgebungsvariablen nutzen kann.
$TEMP = $(TEMP) und entspricht quasi einem %TEMP%

$(TEMP) ist dafür, falls weitere Buchstaben/Zahlen direkt folgen
$TEMPXYZ <> $(TEMP)XYZ

[AThurm]

Ich konnte immer noch nicht rausfinden woran es liegt, ich glaub die Compilierzeit ist einfach so hoch, ich werde jetzt damit leben müssen =)

Ich hatte es mit festen Pfaden im Suchpfad probiert, brachte auch nix.
Die Idee mit AQTime gestaltet sich etwas schwerer, da ich mich zu wenig damit auskenne
Was mir aufgefallen ist, er macht 120.000 Zeilen Code in ein paar Sekunden und bleibt dann bei diversen Dateien 30-40 Sekunden stehn,
allerdings habe ich diese Dateien überprüft und konnte nichts schlimmes feststellen (Dateigröße, Resourcen, Anzahl der Zeilen)

[ChrisE]

Hallo,

hast du mal einen Unit-Uses-Analyser drüber laufen lassen? Das bringt u.U. auch schon echt was dort etwas aus zu misten. Das er ein ein paar Units hängt, könnte schon damit zusammen hängen, dass er große Uses-Listen richtig sortieren muss, um sie entsprechend ab zu arbeiten.

Außerdem hast du geschrieben, dass du per Projektoptionen in der IDE die Zeit verändern konntest aber nicht im CMD-Compiler. Nur so blöd gefragt, hast du diese "Änderungen" der IDE in deine Comandozeilenaufruf übernommen oder per include in jede Unit eingefügt? (per Include müsste ja wirklich in jede Unit aufgenommen werden).

Gruß, Chris