Code-Vervollständigung sehr langsam (D7)

[MatthiasR]

Ich benutze Delphi 7 und habe das Problem, dass IDE-Features wie die Code-Vervollständigung oder die Anzeige der Code-Parameter bei Methodenaufrufen unheimlich langsam reagieren. Das ganze ist aber nur in unserem Hauptprojekt (entsprechend groß) so dramatisch, nicht in kleineren Projekten. Und im Hauptprojekt auch nur in Units, die gewisse andere selbstgeschriebene Units verwenden. Erzeuge ich in unserem Hauptprojekt bspw. ein neues Formular und verwende darin keinerlei andere unserer eigenen Units, so ist die Code-Vervollständigung darin richtig flott. Es muss also an irgendeiner (oder mehrerer) eigenen Unit liegen, die den Aufbau der Code-Vervollständigung dermaßen verlangsamt.

Jetzt ist nur die Frage welche Unit(s) und warum gerade diese die IDE so dermaßen ausbremsen. An der bloßen Größe der Units kann es eigentlich nicht liegen, oder? Schließlich bindet Delphi ja beim Anlegen eines neuen Formulars eine ganze Reihe Delphi-interner Units ein, die allesamt ebenfalls sehr umfangreich sind:

Delphi-Quellcode:

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

Trotzdem ist und bleibt die Code-Vervollständigung pfeilschnell, obwohl sie in dieser Ausgangssituation bestimmt bereits tausende von Klassen, Methoden, Variablen und Konstanten zu "verwalten" hat. Kommen ein paar eigene Units hinzu, so verlangsamt sich das ganze jedoch um mehrere Sekunden (vorher ja nur Bruchteile einer Sekunde).

Was ich mir vorstellen könnte, ist, dass es in den eigenen Units irgendwelche unschönen Konstrukte gibt, die die IDE so dermaßen verlangsamen. Also bspw. irgendwelchen zirkulären Bezüge oder sonst etwas. Also dass Unit A die Unit B verwendet und umgekehrt. Kann das sein? Solche Stellen gibt es leider Gottes, ich könnte den Verursacher dafür auch steinigen :twisted:

Habt ihr gerade bei Delphi 7 auch schon ähnliche Erfahrungen gemacht und wie konntet ihr sie lösen? Oder muss ich mich damit abfinden?

Danke für eure Hilfe!

[hoika]

Hallo,

habe das gleiche Problem.
Ich habe das von automatisch auf manuell gestellt.


Heiko

[himitsu]

zwei einfache Tipps/Tricks:
- schaltet ErrorInsign ab
- nutzt DelphiSpeedUp

Ersteres funktioniert eh nie richtig und bremst nur aus, bzw. sorgt durch falschanzeige von Fehlern für Verwirrungen.

Letzeres tauscht einige Funktionen in der IDE aus (die kompilierten Programme bleiben unberührt)
z.B. den Speichermanager (gegen FastMM) und viele langsame Stringfunktionen.

[MatthiasR]

Zitat:

Zitat von hoika

habe das gleiche Problem.
Ich habe das von automatisch auf manuell gestellt.

Wo macht man das und hat es was gebracht?

Zitat:

Zitat von himitsu

- schaltet ErrorInsign ab
- nutzt DelphiSpeedUp

Wo macht man das in D7 bzw. gibt es das da schon (EDIT: Nein, erst ab D2005)?!? DelphiSpeedUp hatte ich vorhin mal installiert, brachte keine Besserung.

Ist es denn nicht verwunderlich, dass die Probleme nur auftauchen, wenn ich ein paar unserer eigenen Units verwendet und NICHT bei Unmengen Delphi-Units?!? Irgendwas muss doch dann bei unseren eigenen Units falsch laufen?!?

[himitsu]

Bei den DelphiUnits nutzt Delphi eigentlich nur die vorkompilierten DCUs ... zu den Sourcen gibt es nur eine Umleitung für's Debugging und Dergleichen.
Da muß Delphi also nicht viel parsen, um den Aufbau der Units zu kennen.

Hmmm, ganz ehrlich, ich weiß garnicht, dann dieses eingeführt wurde ... hab bei sowas abgestellt, ich dachte aber D7 hätte da auch schon was zu bieten ... nja, konnte aber grade auch nichts zum aktivieren derartiger Funktionen finden :oops:


Bei sowas wäre auch noch eine Idee zu versuchen über die Open Tools API sich an einigen Stellen einzuklinken (wenn swas denn geht) und einige Zeiten zu messen, um so vielleicht rauszubekommen, wo es denn "hängt"

[nahpets]

Hallo,

das Problem kenne ich.

Es tritt immer dann auf, wenn ich ein großes Projekt öffne und dann erstmals auf die Codevervollständigung "warte".
Mir scheint, dass Delphi dann hergeht und erstmal alles an Quelltexten "durcharbeitet" um an die für die Codevervollständigung erforderlichen Informationen zu kommen.

Wenn ich Delphi richtig beobachtet habe, kompiliert es im Hintergrund alle eigenen Units (sprich: nicht die zu Delphi gehörenden) um die Informationen zur Codevervollständigung zu sammeln, es muss halt alle Quelltexte einmal parsen.
Danach bekommt es Änderungen "von allein" mit.

Bei mir hilft es, bevor ich das erste Mal die Codeversollständigung benutze, das Projekt zu compilieren. Dann kommt Delphi "zwangsweise" überall mal vorbei und kann die Informationen sammeln.

Danach geht's dann gewohnt schnell.

[MatthiasR]

Zitat:

Zitat von nahpets

Hallo,

das Problem kenne ich.

Es tritt immer dann auf, wenn ich ein großes Projekt öffne und dann erstmals auf die Codevervollständigung "warte".
Mir scheint, dass Delphi dann hergeht und erstmal alles an Quelltexten "durcharbeitet" um an die für die Codevervollständigung erforderlichen Informationen zu kommen.

Wenn ich Delphi richtig beobachtet habe, kompiliert es im Hintergrund alle eigenen Units (sprich: nicht die zu Delphi gehörenden) um die Informationen zur Codevervollständigung zu sammeln, es muss halt alle Quelltexte einmal parsen.
Danach bekommt es Änderungen "von allein" mit.

Bei mir hilft es, bevor ich das erste Mal die Codeversollständigung benutze, das Projekt zu compilieren. Dann kommt Delphi "zwangsweise" überall mal vorbei und kann die Informationen sammeln.

Danach geht's dann gewohnt schnell.

Dass Delphi beim ersten Aufruf der Code-Vervollständigung immer etwas länger braucht, ist mir auch schon aufgefallen. Jedoch wäre das alleine ja überhaupt kein Problem. Danach funktioniert es ja in der Regel viel schneller. Nur bei meiner Konstellation nicht. Da kommt es mir so vor, als ob die IDE die benötigten Infos jedes mal aufs Neue erzeugen muss, sodass es immer gleich lange dauert (mehrere Sekunden).

Trotzdem probiere ich deinen Tipp jetzt mal aus, zu aller erst mal das Projekt komplett zu Compilieren. Aber große Hoffnungen habe ich nicht... :|

[nahpets]

Hallo,

mehrere Sekunden geht doch, da hab' ich auch schon mal 'ne Minute und länger gewartet (okay, war jetzt nicht unbedingt ein schneller Rechner).

[MatthiasR]

Zitat:

Zitat von nahpets

mehrere Sekunden geht doch, da hab' ich auch schon mal 'ne Minute und länger gewartet (okay, war jetzt nicht unbedingt ein schneller Rechner).

Ist nur so, dass ich das Feature alle paar Sekunden verwende beim Programmieren, um mir Schreibarbeit und potenzielle Verschreiber zu ersparen. Und dann summieren sich die paar Sekunden schnell.

Das Vorcompilieren scheint übrigens in der Tat ein bisschen was gebracht zu haben. Die Verzögerungen sind nicht mehr ganz so extrem. Aber für meine Begriffe immernoch zu lang. V.a. auf einem hochmodernen Entwicklungsrechner (Core2Quad mit 2,66 GHz und 4 GB RAM). Ich bin mal gespannt, ob das nun so bleibt, oder ob sich die Verzögerungen im Laufe der Zeit wieder in die Höhe schrauben.

[nahpets]

Hallo,

Zitat:

Zitat von MatthiasR

Zitat:

Zitat von nahpets

mehrere Sekunden geht doch, da hab' ich auch schon mal 'ne Minute und länger gewartet (okay, war jetzt nicht unbedingt ein schneller Rechner).

Ist nur so, dass ich das Feature alle paar Sekunden verwende beim Programmieren, um mir Schreibarbeit und potenzielle Verschreiber zu ersparen. Und dann summieren sich die paar Sekunden schnell.

Das Vorcompilieren scheint übrigens in der Tat ein bisschen was gebracht zu haben. Die Verzögerungen sind nicht mehr ganz so extrem. Aber für meine Begriffe immernoch zu lang. V.a. auf einem hochmodernen Entwicklungsrechner (Core2Quad mit 2,66 GHz und 4 GB RAM). Ich bin mal gespannt, ob das nun so bleibt, oder ob sich die Verzögerungen im Laufe der Zeit wieder in die Höhe schrauben.

Das mit dem Ersparen der Schreibarbeit habe ich mir abgewöhnt, da immer zu warten ist nervig, da schreib' ich lieber schneller, als Delphi vervollständigt und beim Kompilieren findet es die Verschreiber zuverlässig. Okay, wenn ich mal wieder nicht weiß, welche Parameter eine Funktion oder Prozedure in welcher Reihenfolge benötigt, dann warte ich auch mal. Oder bis man alle Attribute einer Klasse angezeigt bekommt, kann schon mal dauern, geht dann aber bei der gleichen Klasse zukünftig auch recht zügig.

[Sherlock]

Intern läuft da sowas wie ein Compilevorgang, damit die Codevervollständigung geht. Also muss das Compilieren beschleunigt werden. Hilfreich ist da in den Projektoptionen die Compilermeldungen für unsichere Typen, Code und Typumwandlungen abzuschalten.

Sherlock

[nahpets]

Hallo,

Zitat:

Zitat von Sherlock

Intern läuft da sowas wie ein Compilevorgang, damit die Codevervollständigung geht. Also muss das Compilieren beschleunigt werden. Hilfreich ist da in den Projektoptionen die Compilermeldungen für unsichere Typen, Code und Typumwandlungen abzuschalten.

Sherlock

gute Idee, dass Compilieren dauert ja auch endlos lange, wenn da Unmengen von Warnungen ausgegeben werden, weil eigentlich die Ausgabe der Warnungen beinahe schon länger dauert als das Compilieren.

[MatthiasR]

Zitat:

Zitat von Sherlock

Intern läuft da sowas wie ein Compilevorgang, damit die Codevervollständigung geht. Also muss das Compilieren beschleunigt werden. Hilfreich ist da in den Projektoptionen die Compilermeldungen für unsichere Typen, Code und Typumwandlungen abzuschalten.

Leider sind diese drei Meldungsarten bereits deaktiviert bei mir :?

[MatthiasR]

Wobei das eigentliche Problem nicht ist, dass die Code-Vervollständigung so lange dauert, denn darauf habe ich ja einen Einfluss (indem ich sie halt selten benutze). Vielmehr stört mich, dass sich die IDE des öfteren ein paar "Gedenksekunden" genehmigt, auch wenn ich nur mit dem Cursor an irgendeine stelle im Quellcode springe. Ergebnis: 2-3 Sekunden lang nur die Sanduhr, erst dann gehts weiter. Was macht Delphi da im Hintergrund und wie kann ich das abstellen?

[nahpets]

Hallo,

Zitat:

Zitat von MatthiasR

Wobei das eigentliche Problem nicht ist, dass die Code-Vervollständigung so lange dauert, denn darauf habe ich ja einen Einfluss (indem ich sie halt selten benutze). Vielmehr stört mich, dass sich die IDE des öfteren ein paar "Gedenksekunden" genehmigt, auch wenn ich nur mit dem Cursor an irgendeine stelle im Quellcode springe. Ergebnis: 2-3 Sekunden lang nur die Sanduhr, erst dann gehts weiter. Was macht Delphi da im Hintergrund und wie kann ich das abstellen?

wenn Du mit dem Cursor über eine Klasse, Methode oder sonstwas fährst, so zeigt Dir Delphi dort die Definition, Typ ... an. Diese Informationen müssen irgendwoher kommen und das Suchen dieser Informationen dauert bei großen Projekten halt 'ne Weile.
Eventuell stellst Du mal in den Optionen die Verzögerungszeit für Code-Insight etwas höher, so dass nicht schon eine Pause von 'ner halben Sekunde (oder weniger) beim Überfahren dafür sorgt, dass Code-Insight aktive wird.

[MatthiasR]

Zitat:

Zitat von nahpets

Eventuell stellst Du mal in den Optionen die Verzögerungszeit für Code-Insight etwas höher, so dass nicht schon eine Pause von 'ner halben Sekunde (oder weniger) beim Überfahren dafür sorgt, dass Code-Insight aktive wird.

Habe den Wert mal aufs Maximum von 1,5 Sekunden gestellt. Mal schauen, ob es etwas bringt.

Kann es eigentlich sein, dass die Reihenfolge, in der andere Units eingebunden werden, ebenfalls zu Verzögerungen bei der Code-Vervollständigung führen kann? Ich komme darauf, weil ich hier gerade mit zwei Units teste, die beide die gleichen Units verwenden. Die eine Unit verwendet allerdings noch ein paar weitere Units, die die andere Unit nicht verwendet. Kurioserweise dauert der Aufbau der Code-Vervollständigung trotzdem bei der zweiten Unit länger, als bei der ersten, obwohl die IDE da ja weniger Dateien aufzuarbeiten hat.

[nahpets]

Hallo,

wie Delphi da nun vorgeht, kann ich nicht sagen, kenne halt meine "Spezial"-Projekte, bei denen ich warten muss, die werden nach dem Öffnen erstmal kompiliert und die Maus wird so gestellt, dass sie beim Schreiben und/oder Blättern über Tastatur, nicht ausversehen über dem Quelltext steht und eine kleine Pause von 'ne Sekunde Delphi zum Hervorgraben der Hinweise... veranlasst.

Eine sinnvolle Lösung zu dem Problem kann ich nicht liefern, nur so meine Erfahrungen, um damit umzugehen.

[MatthiasR]

Zitat:

Zitat von nahpets

Hallo,

wie Delphi da nun vorgeht, kann ich nicht sagen, kenne halt meine "Spezial"-Projekte, bei denen ich warten muss, die werden nach dem Öffnen erstmal kompiliert und die Maus wird so gestellt, dass sie beim Schreiben und/oder Blättern über Tastatur, nicht ausversehen über dem Quelltext steht und eine kleine Pause von 'ne Sekunde Delphi zum Hervorgraben der Hinweise... veranlasst.

Eine sinnvolle Lösung zu dem Problem kann ich nicht liefern, nur so meine Erfahrungen, um damit umzugehen.

Und das ist doch schonmal ne Menge :) . Ich danke dir! Das hat mir schonmal etwas weitergeholfen. Vielleicht komme ich ja noch irgendwann dahinter, was da genau für die Verzögerungen sorgt...

[berens]

Sorry für das ausgraben dieses alten Threads. Für die Nachwelt:

Der Tip hier hat mir scheinbar geholfen: http://de.comp.lang.delphi.non-tech....vorgang-dauert

Und zwar habe ich sowohl bei den Projektoptionen - Verzeichnisse/Bedingungen - Suchpfad wie auch bei Tools - Optionen - Umgebungsoptionen - Delphi-Optionen - Bibliothek-Win32 - Bibliothekspfad "Ungültige Pfade löschen" angeklickt - seitdem läuft es (aktuell) einwandfrei, und ich bin z.B. bei der Code-Vervollständigung von ca. 25 Sekunden runter auf ~2 Sekunden maximal.

[stahli]

Vorsicht unter XE3.
Da wird u.U. ein benötigter Pfad gelöscht, wodurch die Projekte nicht mehr kompiliert werden konnten. (Gab irgendwas dazu mal in der DP.)

[Union]

Ja, man darf die Pfade NICHT löschen, die bestimmte Variablen (PLATFORM etc.) enthalten da die immer grau dargestellt werden.

[jbg]

Zudem hat XE2 Compiler einen directory listing cache (wenn auch etwas schlecht implementiert), der die vielen Festplattenzugriffe (FileExists) abfängt und ungültige Verzeichnisse aussortiert.