Compilierzeit zu hoch, was ist falsch?

[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

[AThurm]

Mittlerweile habe ich einen Ansatz gefunden der vieleicht was bringen wird, danke an alle!!!
Mithilfe eines Tools lassen sich folgende Fälle darstellen:

Delphi-Quellcode:

unit Unit36;

interface

implementation

uses Unit37;

end.

Delphi-Quellcode:

unit Unit37;

interface

uses Unit36;

implementation

end.

welche ein Zirkulären-Verweis darstellen, ich vermute das sowas den Compiler verlangsamt, da es bei uns massig davon gibt, eine Unit verweist teilweise auf Umwege 84 mal auf sich selber.

Hat hier jemand Erfahrungen gemacht und kann bestätigen, dass das Auflösen solcher Zirkulären Verweise den Compileprozess verbessert?

Zusätzlich alle UNUSED Uses entfernen mithilfe von CCWizard.