IDE bleibt hängen

[Nersgatt]

Moin,

Wenn ich mein Projekt öffne, dann wird bei mir das Hauptformular direkt geöffnet. Das passiert auch in einer akzeptablen Zeit.
Wenn ich dann allerdings das Hauptformular in der IDE schließe, friert die IDE für >5 Minuten komplett ein. Danach reagiert sie wieder und ich kann ganz normal an meinem Projekt arbeiten. Dateien öffnen, schließen, speichern, etc., alles normal. Nur das erste Schließen des Hauptformular in der IDE dauert ewig.

Ich hab keine Idee, woran das liegen könnte.
Ich hab schon probiert, den bds.exe-Prozess als Ausnahme im Defender einzutragen. Hat nichts gebracht. Ich hab auch *.pas und *.dfm als Ausnahme eingetragen. Hat auch nichts gebracht.
Das Verhalten habe ich schon länger (mehrere Monate), hatte aber bisher nicht die Muße, mich damit zu befassen. Da es ja nur 1-2 am Tag nervt, wenn man das Projekt öffnet. Daher kann ich auch nicht mehr nachvollziehen, ob es dafür einen bestimmten Auslöser gab.

Ich arbeite mit

• Berlin 10.1 Update 2
• Windows 8 (Version 6.3, Build 9600)
• Komponenten: DevExpress, UniDAC, TMS

Jemand eine Idee?

[jaenicke]

Was sagt denn in der Zeit der Stacktrace? Wirft die IDE irgendwelche Exceptions im Hintergrund? Passiert in der Zeit etwas im Process Monitor?

[Uwe Raabe]

Falls noch nicht geschehen, kannst du mal versuchen die TrackingSystem<nnn>.bpl aus den Known IDE Packages zu entfernen - sowohl unter HKCU als auch unter HKLM. Ein weiterer Kandidat dafür ist die CommunityToolbar<nnn>.bpl.

[Nersgatt]

Das Entfernen der Packages hat leider nichts gebracht.

Ich hab das dann mal mit dem ProcessMonitor untersucht. Es liegt daran, dass er sich an den DCUs kaputt sucht.
Da kommen wohl mehrere Faktoren zusammen:

• zu einem haben wir unseren Code vor einiger Zeit in Unterordner aufgeteilt, um etwas mehr Struktur rein zu bekommen. Das Projekt ist ziemlich groß, lässt sich aber sehr schön in Themenbereiche abgrenzen. Daher schien die Aufteilung in Unterordner sinnvoll. Die IDE sucht nun alle DCUs erst mal in den Projektordnern.
• Die IDE probiert die Unit-Gültigkeitsbereichsnamen (Projektoptionen) durch. Und das wieder in allen Unterordnern mit allen Units
• In den Projektoptionen habe ich ein "Ausgabeverzeichnis für Units gesetzt", da ich die ganzen DCUs nicht im selben Ordner wie die Quellcodedateien haben möchte. Einfach für die Übersichtlichkeit. Und grade in diesem Ordner (wo die IDE die meisten DCUs sofort finden würde) sucht die IDE scheinbar zuletzt.

Diese Faktoren potenzieren sich natürlich.
Ich werde jetzt erst mal versuchen, ob ich auf die Unit-Gültigkeitsbereichsnamen verzichten kann. Das sollte schon Besserung bringen.

Hat jemand ein Tipp zu dem Ausgabeverzeichnis für die Units? Kann man die Suchreihenfolge irgendwie beeinflussen?

[Uwe Raabe]

Wie sieht denn der Suchpfad des Projekts des aus?

[Nersgatt]

Der Suchpfad des Projekts ist leer. Sollte ich da den Ausgabepfad für die DCUs eintragen? Ich dachte, in den Suchpfad gehört nur der Pfad zu den Quelltexten.

[Uwe Raabe]

Zitat:

Zitat von Nersgatt (Beitrag 1410864)

Ich dachte, in den Suchpfad gehört nur der Pfad zu den Quelltexten.

Das ist auch korrekt so.

Wenn der Suchpfad leer ist, kommt lediglich noch der Bibliothekspfad aus den IDE-Optionen zum Tragen. Allerdings sollte der DCU-Ausgabepfad eigentlich Vorrang haben.

[Nersgatt]

Interessant ist, dass er immer erst die Unit-Gültigkeitsbereichsnamen durchprobiert.

Mal ein Beispiel, wie ich es im ProcessMonitor nachvollziehen kann. Die IDE sucht die Datei "MyServicesUni.dcu" (eine Datei, die zu UniDAC gehört).
Die IDE sucht nun zuerst nach der Datei "WinApi.MyServicesUni.dcu" in folgender Reihenfolge:

1. Projektordner, in der die DPR liegt
2. Debug-DCU-Pfad
3. Bibliothekspfad
4. Unterordner des Projektes

Dies wiederholt die IDE nun für "System.MyServicesUni.dcu", dann für "Data.Win.MyServicesUni.dcu", usw.
Nach 2714 fehlerhaften Suchen nach der Datei, kommt die IDE endlich mal auf die Idee, nach "MyServicesUni.dcu" zu suchen, welche sie dann im Bibliothekspfad findet.
Würde die IDE nicht erst alle Unit-Gültigkeitsbereichsnamen durchprobieren, hätte sie die Datei schon nach 19 Schritten gefunden, nicht erst nach über 2000.

[Uwe Raabe]

Das sind doch eigentlich Dinge, die erst beim Compilieren auftauchen sollten, oder? Könnte es sein, daß hier Code Insight oder irgendein anderes Tool seine Finger im Spiel hat?

[himitsu]

Zitat:

Zitat von Nersgatt (Beitrag 1410870)

Nach 2714 fehlerhaften Suchen nach der Datei, kommt die IDE endlich mal auf die Idee, nach "MyServicesUni.dcu" zu suchen, welche sie dann im Bibliothekspfad findet.

Mal den Andreas fragen, ob er Lust hat dort auch noch einen Cache für die Dateisuche reinzuhacken, damit das Suchen schneller geht. :oops:

[Delphi.Narium]

Wenn mein Delphi 7 auch altpacken ist, am Anfang wird im Hintergrund erstmal kompiliert, um eben die Infos für Code Insight "zusammenzudaddeln". Das hat damals schon bei großen Projekten gedauert und ist heute, bei deutlich mehr Umfang, sicherlich auch nicht unbedingt sehr schnell.

Was mir geholfen hat: Die automatisch erscheinende Programmierhilfe in den IDE-Optionen deaktivieren oder zumindest die Wartezeit, bis sie aufgerufen, möglichst hoch einzustellen (Shortcut Strg+Leertaste funktioniert weiterhin).

Es reicht ja eine (wenn auch unbeabsichtigte) Mausbewegung über den Quelltext aus, um die Programmierhilfe "anzustoßen". Und das dauert dann am Anfang etwas arg lang.

Ist das bei heutigen Delphis eventuell auch noch so?

Was das Suchen nach Dateien angeht: Wenn das so ist, wie beschrieben, wäre das für meine Begriffe ein Fehler. Zuerst sollte nach dem gesucht werden, was im Quelltext steht und nur dann, wenn das nicht gefunden wird, von mir aus auch nach "geratenen" Namenserweiterungen. So, wie beschrieben, erscheint mir das suboptimal. Das sollte man (find' ich) als Fehler melden.

[Nersgatt]

Also, ich hab jetzt die Bereichsnamen auf das allernötigste eingedampft (da stand noch "bde" drin :stupid: ). Jetzt es ist schon spürbar schneller.
Ob ich die Verzeichnisstruktur wieder etwas flacher mache, muss ich mir noch überlegen. Das würde sicher auch noch wieder einiges bringen. Aber darauf möchte ich eigentlich nicht verzichten.

[Uwe Raabe]

Ich hatte mal einen Vergleich der Compilierzeiten für den MMX Code Explorer gemacht, wobei für die Compiler < CE2 mal mit und mal ohne die Unit-Scope-Names compiliert wurde. Wenn das in deinem Fall verantwortliche Element dort ebenso reagiert, erklärt das den wahrgenommenen Effekt.

Leider kann ich beim MMX erst auf die Scope-Names verzichten, wenn ich den Support für die älteren Delphi-Versionen einstelle - das ist aber schon für die nahe Zukunft geplant.

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1410873)

Mal den Andreas fragen, ob er Lust hat dort auch noch einen Cache für die Dateisuche reinzuhacken, damit das Suchen schneller geht. :oops:

Da muss ich nicht viel machen, denn das ist schon im IDEFixPack enthalten. Wenn es installiert ist, sieht man nur noch das Einlesen der gesamten Verzeichnisstruktur (FindFirstFile/FindNextFile) und nicht mehr das "filename probing".

[Nersgatt]

Super! Mit dem FixPack ist es um ein vielfaches schneller. Ich danke Dir! :thumb: