Delphi 2010 unglaublich langsam

[magicsnail]

Moin!

Wir entwickeln seit vielen Jahren mit Delphi7. Ewig wird das wohl nicht mehr weitergehen, also haben wir uns mal die 2010-Version und dazu einen Windows7-Rechner besorgt.

Und jetzt stellen wir verblüfft fest: Für die Übersetzung eines Programmes, welches von Delphi7 in nicht wahrnehmbarer Zeit übersetzt wird (Strg-F9), braucht die 2010-Version ca. 30 Sekunden. Da staunt der Laie und der Fachmann wundert sich.

Aber es kommt noch schlimmer: Sobald man in der IDE eine Klammer-Auf "(" oder einen Punkt hinter einem Objekt eintippt, genehmigt sich 2010 ebenfalls 30 Sekunden um die integrierte Hilfe zu aktivieren. Nahezu jedes mal. Weitertippen kann man während dieser Wartezeit nicht. Ein flüssiges Arbeiten ist auf diese Weise also völlig unmöglich.

Was läuft denn da schief? Haben wir irgendwo in den Systemeinstellungen den Haken bei "nicht 30 Sekunden auf die Hilfe warten" nicht gesetzt? Haben andere ähnliche Probleme? Kann man das sonstwie beschleunigen?

Vielen Dank schon mal für Tipps im Voraus!

[Bernhard Geyer]

Schalte mal ErrorInsight ab.

[magicsnail]

Zitat:

Zitat von Bernhard Geyer

Schalte mal ErrorInsight ab.

Wie?

[Luckie]

In den Optionen?

[Neutral General]

Habe hier das gleiche Problem mit Delphi 2009.

Meine Einstellungen sehen so aus:

http://img96.imageshack.us/img96/2470/optionen.jpg

Kann man das irgendwie noch optimieren?

Ein weiteres Problem was ich z.T. habe, ist, dass Delphi meine Einstellungen z.T. eigenständig zurücksetzt.

[cookie22]

die autovervollständigung ist extrem langsam. oft kommt bei mir ne sanduhr und das fenster geht garnicht auf, je mehr units im projekt umso langsamer, so kommts mir jedenfalls vor.

[magicsnail]

Ich hab jetzt mal die verschiedenen Optionen-Menüs und Unter-Unter-Menüs durchsucht und hab auch den Entsprechenden Reiter Tools | Optionen | Code Insight gefunden. (Weia ist das unübersichtlich.)

Tatsächlich beschleunigt das Herausnehmen des Hakens bei "Fehlermarkierung" das Eingeben eines Punktes hinter einem Objekt auf Normalmaß. Schade, denn die Funktion "Fehlermarkierung" wäre ja durchaus hilfreich gewesen.

Weiterhin beschleunigt das Herausnehmen des Hakens bei "Code-Parameter" das Eingeben von Klammern für Funktionen. Nur werden dann die durchaus hilfreichen Parameterangaben nicht mehr angezeigt.

Ich muss also gute Teile der IDE abschalten, damit sie überhaupt benutzbar wird. Was soll das denn?! Die zuvor genannten 30 Sekunden Systemstillstand waren übrigens keine gefühlten, sondern gemessene Sekunden!

Auf die verfünfzigfachung der Übersetzungszeit gegenüber Delphi7 haben diese beiden Haken allerdings leider keinen Einfluss (nicht dass ich das erwartet hätte). Gibt es da auch noch einen Haken?

[cookie22]

die fehlermarkierung funktioniert eh nicht richtig das ist kein wirklicher verlust.

[dataspider]

Hi,

was IMHO auch bremst, sind zu viele eingeschaltete Meldungen im Debugger - Ereignisprotokoll.

Frank

[hoika]

Hallo,

wie bei jedem Delphi (ausser 5->6) wird es etwas langsamer,
falls der gleiche Rechner benutzt wird.
Von irgendwas muss ja die IDE-Verbesserungen kommen.
(Das war jetzt nicht ironisch)

Zitat:

dazu einen Windows7-Rechner besorgt.

Was ist das denn für ein "Windows7-Rechner" (Prozessor/RAM) ?


Heiko

[Neutral General]

Kann mir evtl. jemand sagen warum Delphi die Einstellungen die ich unter "Code Insight" mache dauernd ignoriert?

[magicsnail]

Zitat:

Zitat von hoika

wie bei jedem Delphi (ausser 5->6) wird es etwas langsamer,
falls der gleiche Rechner benutzt wird.
Von irgendwas muss ja die IDE-Verbesserungen kommen.
(Das war jetzt nicht ironisch)

Zitat:

dazu einen Windows7-Rechner besorgt.

Was ist das denn für ein "Windows7-Rechner" (Prozessor/RAM) ?

AMD Athlon Dual Core Processor 4850e 2.5GHz
2 GB Arbeitsspeicher
64 Bit Betriebssystem

Das sollte doch eigentlich ausreichen und die etwas umfangreicheren IDE-Verbesserungen auffangen, oder?
Das ist ja auch nicht "etwas langsamer" sondern die Kiste steht. Und die alte Möhre mit Delphi7 zuckt nicht mal...

[magicsnail]

Zitat:

Zitat von dataspider

was IMHO auch bremst, sind zu viele eingeschaltete Meldungen im Debugger - Ereignisprotokoll.

Auch da habe ich unter Tools | Optionen | Ergebnisprotokoll | Meldungen was zum Abhaken gefunden.
Nämlich einfach mal alle Meldungen. Leider kein Effekt auf die Kompilier-Zeit.

Ich hab jetzt noch mal genau nachgemessen:

Kompilierzeit in Delphi7: mal 3 Sekunden mal unter einer.
Kompilierzeit in Delphi10: 1:07 Minuten.

Das steht in keinem Verhältnis...

[Uwe Raabe]

Also normal ist das jedenfalls nicht. Ich habe bei meinem Delphi 2010 auch nicht den ganzen Kram abgeschaltet und es ist trotzdem nicht (zumindest nicht wahrnehmbar) langsamer als Delphi 7.

Handelt es sich exakt um dieselben Dateien oder sind das zwei unterschiedliche Sourcen, die du kompilierst? Es reicht manchmal schon auf nicht-lokale Verzeichnisse zuzugreifen, um das System auszubremsen. Schreibgeschützte Source-Dateien sind auch schon mal als Übeltäter entlarvt worden.

Ich hatte das Problem auch, als ich Delphi in einer VM laufen ließ, die Sourcen und Bibliotheken aber auf einem "Shared Folder"-Verzeichnis lagen.

[himitsu]

Eventuell kann auch etwas davon ein bissl helfen?

IDE Fix Pack - http://www.delphipraxis.net/internal...t.php?t=128432
DelphiSpeedUp - http://www.delphipraxis.net/internal...ct.php?t=80522

[Lemmy]

Zitat:

Zitat von magicsnail

AMD Athlon Dual Core Processor 4850e 2.5GHz
2 GB Arbeitsspeicher
64 Bit Betriebssystem

das ist jetzt nicht dein Ernst oder? 2 GB reichen doch gerade mal für Windows aus. Unter 4 GByte würde ich nicht mal MS Office starten ;-) So und jetzt mal im Ernst: 4 Gbyte mindestens. Auch wenn Windows 7 zu Windows Vista "schneller" geworden ist, aber unter 4Gbyte würde ich heute keinen Entwickler-Rechner mehr anschaffen. Und ja: Die Compilierung ist von Delphi 7 auf Delphi 2009/2010 langsamer geworden. Wenn dann noch Vista dazu kommt werden aus 10 Sekunden 10 Minuten.

Grüße
Lemmy

[Neutral General]

Zitat:

Zitat von Lemmy

Zitat:

Zitat von magicsnail

AMD Athlon Dual Core Processor 4850e 2.5GHz
2 GB Arbeitsspeicher
64 Bit Betriebssystem

das ist jetzt nicht dein Ernst oder? 2 GB reichen doch gerade mal für Windows aus. Unter 4 GByte würde ich nicht mal MS Office starten ;-) So und jetzt mal im Ernst: 4 Gbyte mindestens. Auch wenn Windows 7 zu Windows Vista "schneller" geworden ist, aber unter 4Gbyte würde ich heute keinen Entwickler-Rechner mehr anschaffen. Und ja: Die Compilierung ist von Delphi 7 auf Delphi 2009/2010 langsamer geworden. Wenn dann noch Vista dazu kommt werden aus 10 Sekunden 10 Minuten.

Bisschen schwer übertrieben oder?

[himitsu]

Zitat:

Zitat von Neutral General

Bisschen schwer übertrieben oder?

Daß es immer langamer wird, ist doch unbestritten, auch wenn das vorhin ein klitzekleines bissl übertrieben war.
(das ist einer der Gründe, warum ich nebenbei immernoch ein D7 instlalliert hab)

[Neutral General]

Jo natürlich gehts (bis zu einer gewissen Grenze) umso schneller desto mehr Arbeitsspeicher man hat, aber ich hab auf meinem Laptop mit Win7, Delphi2010, 1,8GHz Dualcore und 3GB RAM absolut keine Probleme.. Und ich glaube nicht, dass ich mit 1 GB weniger Probleme hätte..

[Insider2004]

Die Langsamkeit kommt von .net. Das muss erst geladen und übersetzt werden (ähnlich wie bei java). Delphi 7 arbeitet ohne .net, also native und ist deshalb erbeblich schneller.

[jbg]

Zitat:

Zitat von Insider2004

Die Langsamkeit kommt von .net. Das muss erst geladen und übersetzt werden (ähnlich wie bei java). Delphi 7 arbeitet ohne .net, also native und ist deshalb erbeblich schneller.

Nur das .NET nicht zum kompilieren benutzt wird. Der IDE Compiler ist eine "handelsübliche" DLL, die in C geschrieben ist.

[Insider2004]

Zitat:

Zitat von jbg

Zitat:

Zitat von Insider2004

Die Langsamkeit kommt von .net. Das muss erst geladen und übersetzt werden (ähnlich wie bei java). Delphi 7 arbeitet ohne .net, also native und ist deshalb erbeblich schneller.

Nur das .NET nicht zum kompilieren benutzt wird. Der IDE Compiler ist eine "handelsübliche" DLL, die in C geschrieben ist.

Korrekt. Ich meinte auch, dass das Programm erst für .net übersetzt werden muss (sprich auf den Zielprozessor).

[Uwe Raabe]

Zitat:

Zitat von Insider2004

Ich meinte auch, dass das Programm erst für .net übersetzt werden muss (sprich auf den Zielprozessor).

Das hat alles nichts mit dem Kompiliervorgang zu tun. Und wie gesagt, hier ist mit D2010 gar nichts wahrnehmbar langsamer als mit D7...

[Insider2004]

Zitat:

Zitat von Uwe Raabe

Zitat:

Zitat von Insider2004

Ich meinte auch, dass das Programm erst für .net übersetzt werden muss (sprich auf den Zielprozessor).

Das hat alles nichts mit dem Kompiliervorgang zu tun. Und wie gesagt, hier ist mit D2010 gar nichts wahrnehmbar langsamer als mit D7...

Mit "Programm" meine ich die .net-Teile in der Delphi 2010-IDE.

[Daniel]

Zitat:

Zitat von Insider2004

Ich meinte auch, dass das Programm erst für .net übersetzt werden muss (sprich auf den Zielprozessor).

und

Zitat:

Zitat von Insider2004

Mit "Programm" meine ich die .net-Teile in der Delphi 2010-IDE.

Das hat doch nichts mit dem Übersetzen des Delphi-Projektes zutun.

[Lemmy]

Hi,

die 10 Minuten unter VIsta und Delphi 2007 ist nicht übertrieben. Unter XP und Delphi 2007 war die Zeit noch akzeptabel, unter VIsta dauerte das ganze dann einfach so lange. Nach einem Tag habe ich dann wieder unter XP entwickelt (VMWare mit XP auf der VIsta-Maschine und war dennoch schneller).

Hinweis: War Delphi 2007 ohne Updates und ohne die AH-Patches..

Ach ja: Versuchsweise habe ich Vista auch mal neu installiert - brachte auch keine Verbesserung...

Grüße
Lemmy

[mirage228]

Also, was bei meinem Delphi 2010 an der Code-Vervollständigung langsam war, war die Option "Symbolbeschreibung".

Ich habe hier einen Core i7 laufen (4 GB RAM, Win 7 Prof.) und die Code-Vervollständigung wurde bei einer größeren Unit von mir recht langsam. Allerdings hakte sie nur, falls ich "zu lange" auf einem Eintrag geblieben, sodass das zusätzliche Hint-Fenster neben der Code-Vervollständigung angezeigt werden sollte. Das führte schon zu einer recht merkbaren Verzögerung von teilweise über 1 Sekunde.
Vielleicht liegts bei Dir ja auch daran.

Viele Grüße

[cookie22]

bei mir ist nur die code-vervollständigung so langsam, das compilieren ist bei mir recht flott.

das dort ein unterschied zu delphi 7 ist sollte klar sein es werden doch viel mehr informationen verarbeitet, z.B. der ganze RTTI kram.

[Insider2004]

Zitat:

Zitat von Daniel

Zitat:

Zitat von Insider2004

Ich meinte auch, dass das Programm erst für .net übersetzt werden muss (sprich auf den Zielprozessor).

und

Zitat:

Zitat von Insider2004

Mit "Programm" meine ich die .net-Teile in der Delphi 2010-IDE.

Das hat doch nichts mit dem Übersetzen des Delphi-Projektes zutun.

Das hat schon mit der Übersetzung zu tun, weil dafür MSBuild verwendet wird. MSBuild ist in .net geschrieben. Beim ersten Übersetzen muss MSBuild selbst übersetzt werden (eine Art jitten). Das kostet sehr viel Zeit, wie bei allen Interpreter und Pseudointerpretersprachen wie z.b. java.

[Uwe Raabe]

Zitat:

Zitat von Insider2004

Beim ersten Übersetzen muss MSBuild selbst übersetzt werden (eine Art jitten). Das kostet sehr viel Zeit, wie bei allen Interpreter und Pseudointerpretersprachen wie z.b. java.

Also "so" viel Zeit kann das nicht sein, denn der Kompiliervorgang (sprich: Zeilenzähler) startet hier quasi sofort.

Gerade gemessen:
D2010: ca. 700.000 Code-Zeilen in ca. 50 Verzeichnissen: 11 Sekunden (nach Hochfahren des System und direkt nach Start D2010)

D7: ca. 180.000 Code-Zeilen in ca. 30 Verzeichnissen: 15 Sekunden (direkt nach Start D7)

System: Core i7, 6GB, Win7 x64

[Die Muhkuh]

Hi,

ich portiere gerade ein Projekt von Delphi 5 auf Delphi 2009, diverse Zusatzkomponenten drin (WPTool, QuantumGrid, AnyDAC, TeeChart), der Kompiliervorgang ist kaum langsamer als im Delphi 5.

Core²Duo 2,4GHZ, 4GB Ram, Win7 Ultimate 64 Bit.

[lowmax_5]

Hallo,

hinsichtlich eines langsamen CodeInsight habe ich folgende Erfahrung gemacht:

:!: 'Der Indexdienst sollte aktiviert sein! :!:

Einstellungen/Systemsteuerung/Verwaltung/Dienste ==> Indexdienst aktivieren.

Nun bitte ca. 30-min bis 1 Std warten bis der Index aufgebaut ist. Erst dann hat man volle Performance bei CodeInsight und eine ordentliche Antwortgeschwindigkeit.

Lowmax

[jbg]

[QUOTE=lowmax_5;1137292]Indexdienst aktivieren.[/qoute]
Bist du dir da sicher? Denn CodeInsight (Strg+Leertaste) nutzt den Indexdienst nicht. Das einzige was dir der Indexdienst hier bringt, ist, dass nach nach der einmaligen Indizierung (deine 30-min bis 1 Std) die Dateien im Dateicache von Windows sind, und somit nicht mehr direkt auf die Platte zugegriffen werden muss. Beim nächsten Neustart ist der Dateicache wieder leer und das Warten beginnt von vorne. Der Indexdienst indiziert aber nicht erneut, da er das ja schon getan hat.

[lowmax_5]

Hallo Andreas,

ich hatte zumindest subjektiv den Eindruck, dass 'CodeInsight' bei akiviertem Index kürzere Anwortzeiten hat, insbesondere, wenn beim ersten Aufruf die Unit zuerst einmal gesucht werden muss.

Ich habe 'Code Insight' per default aktiviert (Programmierhilfe= True - Kein Start mit STRG+SPACE).

Das Projekt hat ca. 280T Codezeilen und hat leider ca. 20T davon in einer sehr groessen Unit (Ich weiss, dass ist suboptimal ;-)). Hier ist die Belastung des Rechners schon erheblich, zumal anscheinend regelmäßig die gesamte Unit immer wieder komplett geparst wird. Ich versehe daher nicht, warum CG/Emb. nicht das Delta analysiert zzgl. den bereits geparsten Code. Das würde doch erheblich schneller laufen, da der Vorgang nicht jedesmal aufs Neue gestartet wird.

lowmax

[jbg]

Zitat:

Zitat von lowmax_5 (Beitrag 1137538)

Ich versehe daher nicht, warum CG/Emb. nicht das Delta analysiert

Wenn du unter "Delta" die veränderten Dateien meinst, dann tun bzw. taten sie das schon. Der Compiler muss aber dafür alle Abhängigkeiten auflösen, was bei schlecht für den Compiler organisiertem Code zu einem riesigen Baum führen kann (Unit A bracht B, braucht C, D, E, F, ..., Z und Z wurde verändert). Da der Compiler aber wohl Probleme hat wenn er mehrfach von anderen Punkten als der DPR Datei einsteigt, hat Embarcadero mit jedem Release mehr "Clear Compiler Cache" Aufrufe eingeführt. Mein IDE Fix Pack entfernt manche davon und markiert dafür einzelne Unit-Zweige als "modified".

[lowmax_5]

... wenn ich Dich Deine Antwort richtig verstehe, macht es wohl am meisten Sinn den Code so reorganisieren, dass möglichst die Zahl der Referenzen (uses...) auf andere Units reduziert wird. Ist den die die Groesse einer Unit auch relevant für die Performance? Das gleiche Projekt lief seinerzeit auf D7 optimal in der Geschwindigkeit. Kommt D2010 zum Einsatz dauert der Aufruf von CodeInsight noch länger, so dass die Eingabe von Code kaum noch möglich ist. Mein Gefühl ist, dass CodeInsight nicht optimal umgesetzt ist, um mit 'nicht optimal strukturierten' Projekten klarzukommen.


PS: Das IDE Fix-Pack habe ich natürlich schon eingespielt!

[jbg]

Zitat:

Zitat von lowmax_5 (Beitrag 1137602)

Kommt D2010 zum Einsatz dauert der Aufruf von CodeInsight noch länger

Wäre mal interessant ob es an der Festplatte liegt (viele Dateien) oder ob da wirklich der Compiler schuld daran ist.

Zitat:

Mein Gefühl ist, dass CodeInsight nicht optimal umgesetzt ist, um mit 'nicht optimal strukturierten' Projekten klarzukommen.

CodeInsight wird vom echten Compiler mit abgeklemmten Backend (aka Codeerzeugung) durchgeführt (habe ich mal gelesen). Und der Compiler ist natürlich so geschrieben, dass er am besten Projekte kompiliert. Zudem macht es das DCU Format unmöglich Teil-Kompilierungen durchzuführen, da immer alle Units, die von der veränderten Unit abhängen neu kompiliert werden müssen. Ist bei C++ aber auch nicht wirklich anders.

Zitat:

Das IDE Fix-Pack habe ich natürlich schon eingespielt!

Welche Version? Mit 4.5 hat der Compiler nochmal ordentlich zugelegt, vor allem bei längeren Units.

[lowmax_5]

Zitat:

Welche Version? Mit 4.5 hat der Compiler nochmal ordentlich zugelegt, vor allem bei längeren Units.

Bei D2010 hatte ich 4.2 im Einsatz ==> Update auf 4.51

Bei D2007 habe ich versucht die 4.4 herunterzuladen.
In Delphi wird aber seltsamerweise immer nur 4.3 angezeigt. Ist dieses korrekt so?

lowmax

[jbg]

Zitat:

Zitat von lowmax_5 (Beitrag 1137654)

In Delphi wird aber seltsamerweise immer nur 4.3 angezeigt. Ist dieses korrekt so?

Ja. Ich hatte vergessen die Versionsnummer hochzuzählen.