Delphi XE2: IDE extrem langsam

[jbg]

Zitat:

Zitat von hanspeter (Beitrag 1129979)

Fehlermeldung VCL Form inkompatibel zu VCL.Form.

IDE Fix Pack hast du (hoffentlich) wieder deinstalliert. Ansonsten könnte das auch durch dieses hervorgerufen werden.

[QuickAndDirty]

Zitat:

Zitat von Delphi-Laie (Beitrag 1129776)

Also so eine Art "Sozialpartnerschaft"?! Schmusekurs statt konträrer Interessen? Könnte ich genauso den "LOLLY" ausfahren.
Das hat ungefähr die gleiche "Logik" wie die, daß man nicht gegen Krankheitserreger, Parasiten usw. vorgehen muß, da diese ja (angeblich) kein Interesse daran haben (können), dem Wirt zu schaden, denn wenn der stirbt, sind die selbst dran.

Kannst Embarcadero ja gern noch mit einer Benefizspende zusätzlich alimentieren, damit die auch ja möglichst viel Geld bekommen, damit die um Himmels Willen nicht pleitegehen.

Grotesk.

Nein, wie auch immer man das bezeichnen magst, es ist eine Schicksalsgemeinschaft und so lange Embarcadero quasi Monopolist, ist bleibt das auch so. Zumindest für meinen Arbeitgeber wären die Kosten für einen Wechsel weg von Delphi hin zu Lazarus oder ISO C++ wirklich sehr sehr teuer...hier wurde 20 Jahre lang mit Delphi entwickelt... diese Masse an Code löst du nicht mal eben ab. Fast das gesammte Firmenkapital liegt quasi in Delphicode vor.
Ich denke sehr sehr vielen Embarcaderokunden geht es genauso. Ja auch wir leiden unter der sehr beknackten Lizenzpolitik und den immer weiter steigenden Preisen...aber der Login Effekt zwingt uns nunmal dazu für Emba das beste zu hoffen und das sie hübsch viel verkaufen...sonnst werden die noch teurer.
Ein juristischer Sieg über Emba und eine Rückabwicklung des Kaufvertrages Zug um Zug würde das ganze Unternehmen killen.

[hanspeter]

Zitat:

Zitat von jbg (Beitrag 1129983)

IDE Fix Pack hast du (hoffentlich) wieder deinstalliert. Ansonsten könnte das auch durch dieses hervorgerufen werden.

Nein noch nicht. Und ja nach der Installation kam der Fehler.
Da habe ich wenigstens gemerkt, das ich alle Uses überarbeiten muss.

Gruß
Peter

[Delphi-Laie]

Zitat:

Zitat von QuickAndDirty (Beitrag 1129984)

Zitat:

Zitat von Delphi-Laie (Beitrag 1129776)

Also so eine Art "Sozialpartnerschaft"?! Schmusekurs statt konträrer Interessen? Könnte ich genauso den "LOLLY" ausfahren.
Das hat ungefähr die gleiche "Logik" wie die, daß man nicht gegen Krankheitserreger, Parasiten usw. vorgehen muß, da diese ja (angeblich) kein Interesse daran haben (können), dem Wirt zu schaden, denn wenn der stirbt, sind die selbst dran.

Kannst Embarcadero ja gern noch mit einer Benefizspende zusätzlich alimentieren, damit die auch ja möglichst viel Geld bekommen, damit die um Himmels Willen nicht pleitegehen.

Grotesk.

Nein, wie auch immer man das bezeichnen magst, es ist eine Schicksalsgemeinschaft und so lange Embarcadero quasi Monopolist, ist bleibt das auch so. Zumindest für meinen Arbeitgeber wären die Kosten für einen Wechsel weg von Delphi hin zu Lazarus oder ISO C++ wirklich sehr sehr teuer...hier wurde 20 Jahre lang mit Delphi entwickelt... diese Masse an Code löst du nicht mal eben ab. Fast das gesammte Firmenkapital liegt quasi in Delphicode vor.
Ich denke sehr sehr vielen Embarcaderokunden geht es genauso. Ja auch wir leiden unter der sehr beknackten Lizenzpolitik und den immer weiter steigenden Preisen...aber der Login Effekt zwingt uns nunmal dazu für Emba das beste zu hoffen und das sie hübsch viel verkaufen...sonnst werden die noch teurer.
Ein juristischer Sieg über Emba und eine Rückabwicklung des Kaufvertrages Zug um Zug würde das ganze Unternehmen killen.

Das erklärt einiges, danke!

Wie ein "Lolly" (Deine erste Reaktion) klingt das aber keinesfalls mehr, eher wie eine Abhängigkeit auf Gedeih' und Verderb', die Dir/Euch das Lachen vergehen ließ. Es liest sich wie das Satteln des falschen Pferdes. Wenn ich mir jedoch Pascal als sehr leserliche und strukturierte Programmiersprache ansehe, mag ich das nicht so recht glauben. Dumm ist eben nur, daß es nur noch einen kommerziellen Anbieter dafür gibt.

Die Rückabwicklung des Kaufvertrages "Zug um Zuge", ich wiederhole mich jetzt, ist ja nur die allerletzte Möglichkeit. Vorher steht der Produzent in dem Recht und in der Pflicht zu mehrmaligen Nachbesserung(sversuch)en. Embarcadero wird die Fehler schon nach und nach ausbügeln.

Weniger lustig sind allerdings die Produktivitätsausfälle wegen der "Gammatesterei" und der Fehler, die man umständlich umgehen muß, bis zur - manchmal langatmigen - Zeit, bis man an die Korrekturen gelangt. Wenn man die beim Hersteller eingesparten Qualitätskontroll-/-sicherungskosten wenigstens an den Endprodukten wahrnähme...

[Union]

Zitat:

Weniger lustig sind allerdings die Produktivitätsausfälle wegen der "Gammatesterei" und der Fehler, die man umständlich umgehen muß, bis zur - manchmal langatmigen - Zeit, bis man an die Korrekturen gelangt. Wenn man die beim Hersteller eingesparten Qualitätskontroll-/-sicherungskosten wenigstens an den Endprodukten wahrnähme...

Wenn man dann das hier liest, kommt man sich regelrecht verarscht vor.

Ich schlage die QA-Methode "Eat your own dogfood" vor:

Alle internen Embarcadero-Produkte (Buchhaltung, Auftragsbearbeitung, qc...) müssen von den Mitarbeitern auf die neuesten Versionen der eigenen Entwicklungsumgebungen migriert werden.

So KÖNNEN nur weitgehend fehlerfreie Produkte rausgehen. Denn solange die Buchhaltung und Auftragsbearbeitung nicht funktionieren, kann man auch nichts verkaufen.

Am besten auch noch ein eigenes E-Mail und Blog-System auf selbtsgeschriebenem Webserver, dann kann auch kein Mist mehr verfrüht abgesondert werden.

[RWarnecke]

Hallo Leutz,

irgendwie kommt man hier komplett ab vom Thema. Mich interessiert es, warum die IDE extreme langsam ist. Ich versuche nämlich auch Fehler in der IDE herauszubekommen, warum diese passieren.

Deshalb würde ich euch bitte die jetzige Diskussion mit Rückabwicklung und Mängeln doch in einem gesonderten Thread zu bereden.

[Union]

Die Gründe für die Langsamkeit liegen ja nicht an den Mondphasen, sondern an mangelnder QA. Deshalb hat das sehr wohl mit dem Thema zu tun. Und wer sich nicht bei Embarcadero beschwert oder das in qa einträgt oder voted oder commented kann warten bis er schwarz wird. Von alleine wird nichts passieren.

[RWarnecke]

Zitat:

Zitat von Union (Beitrag 1130065)

Die Gründe für die Langsamkeit liegen ja nicht an den Mondphasen, sondern an mangelnder QA. Deshalb hat das sehr wohl mit dem Thema zu tun. Und wer sich nicht bei Embarcadero beschwert oder das in qa einträgt oder voted oder commented kann warten bis er schwarz wird. Von alleine wird nichts passieren.

Ich verweise nur auf den Abschnitt hier :

Zitat:

Zitat von hanspeter (Beitrag 1129979)

Nein daran liegt es auch nicht.
Das Verhalten tritt im Projekt exakt mit einer Form auf und ist bei anderen Forms im gleichen Projekt nicht nachvollziehbar.
Ich habe inzwischen irgendeine Komponente im Verdacht. In dem Projekt verwende ich allerdings nur Standardkomponenten aus dem Lieferumfang.

Auch wenn ich mich jetzt unbeliebt machen sollte, warum sollte daran Emba schuld haben, wenn es nur bei einer einzigen Form in dem Projekt auftaucht ? Man kann nachher Schimpfen auf Emba, wenn Emba auch die Schuld trifft, aber erstmal sollte man schauen, ob seinem Sourcecode alles richtig ist. Es kann ja auch sein, dass eine Komponenten erweitert wurde und mehr Funktionen zur Verfügung hat und deshalb das Problem auftritt. Ich hatte auch schon die komischsten Effekte in niedrigeren Version wie XE2, dass der Designer gesponnen hat.
Desweiteren hast Du ja in einem anderen Beitrag auch zugegeben, dass Du die IDE auch schon öfters auf's Kreuz gelegt hast, als Du die OpenToolsAPI verwendet hast.

So nun zurück zum Thema. Was ich heute Abend festgestellt habe, ist dass die IDE aus irgendeinem Grund immer die Funktion

Delphi-Quellcode:

procedure TIdeNotifier.BeforeCompile(const Project: IOTAProject; var Cancel: Boolean);

aus dem Package-Experten aufgerufen hat, wo ich Quelltext eingegeben habe. Kann das sein, dass er immer versucht einen Teil zu kompilieren ?

[squetk]

Ich hab da noch was zum Thema:

Da ich mit Delphi XE2 automatisch auch Lizenzen für die älteren Versionen gekauft habe, habe ich mal Delphi XE auf meinem superschnellen W7-PC (64bit) mit 16GB RAM installiert:
Auch hier läuft die Codevervollständigung im dicken Projekt angenehm schnell.

An der Stelle muss XE2 irgendwas anders machen.

[RWarnecke]

Da fällt mir gerade noch ein Grund ein, warum die Codeverfollständigung ausgebremst werden kann. Eine Version vom Experten CNPack war mal unter Delphi 2007 ein Grund dafür.

[squetk]

CnPack habe ich nicht installiert.
GExperts ja, aber das habe ich eben mal testweise deinstalliert - Code Insight ist bei XE2 im großen Projekt immer noch lahm.

[RWarnecke]

Zitat:

Zitat von squetk (Beitrag 1130112)

Code Insight ist bei XE2 im großen Projekt immer noch lahm.

Wie definierst Du groß ? Meine größten Projekte sind ca. 26000 Zeilen und ca. 43000 Zeilen. Gehören diese Größen in den Bereich womit Du getestet hast ? Wo hast Du das Projekt und die dazugehörigen Dateien gespeichert ? Lokal oder im Netz ?

[squetk]

Es handelt sich um ca. 500 Units und 700.000 Zeilen Code.

Ist aber für Delphi 2009 und Delphi XE auf dem selben PC kein Thema - geht alles flott.
Nur XE2 lahmt beim Code Insight (ist sonst aber auch flott).

Ich werde noch mal andere PC's probieren.

[jbg]

Zitat:

Zitat von squetk (Beitrag 1130119)

Es handelt sich um ca. 500 Units und 700.000 Zeilen Code.

Benutzt das Programm Runtime Packages (rtl160.bpl, vcl160.bpl, ...) ?

[hanspeter]

Ich habe die Form , welche 14 sec. zum Umschalten zwischen Code und Design benötigt, in ein eigenes Verzeichnis kopiert und ein neues Projekt eingebunden.
Hier der gleiche Effekt.
Dann habe ich nach und nach alle Komponenten gelöscht, bis die blanke Form übrig blieb.
Auch beim Umschalten auf eine jetzt leere Form mehr als 10 sec Wartezeit.
Dann habe ich einfach nur Code gelöscht. (Ist ein altes Programm mit 9000 Zeilen Quellcode)
So unterhalb von 2000 Quellzeilen war dann Bewegung zu spüren eund die Umschaltung erfolgte spürbar schneller.
Bei den von mir angelegten Forms, tritt der Effekt nicht auf, da ich hier GUI und Code getrennt habe und diese deutlich kleiner sind.
Interessant ist, das in dieser großen Form auch der Editor sichtbar verzögert auf Tastendruck reagiert.
3 bis 4 Buchstaben Verzögerung sind die Regel.
Abschalten der Hintergrund-Compilierung bringt keinen Effekt.

Gruß
Peter

[squetk]

Für den ersten Test hatte ich keine Laufzeitpackages verwendet.
Aber auch wenn ich welche angebe, ändert sich nix.

Das verzögerte Umschalten Code/Formularansicht bei Forms mit vielen Controls habe ich auch - aber nur beim ersten Mal, jedes weitere Umschalten geht flott.

[squetk]

Zwischenstand:
Das aktuelle Update für XE2 und das IDE Fix Pack vom 2.11.11 haben keine Besserung bewirkt.

[Delphi-Laie]

Zitat:

Zitat von squetk (Beitrag 1134403)

Zwischenstand:
Das aktuelle Update für XE2 und das IDE Fix Pack vom 2.11.11 haben keine Besserung bewirkt.

Wurde der Fehler denn Embarcadero gemeldet - am besten ganz offiziell über den sog. Bugtrucker?

Falls ja, wie sieht der aktuelle Bearbeitungsstand aus?

[hanspeter]

Zitat:

Zitat von Delphi-Laie (Beitrag 1134457)

Wurde der Fehler denn Embarcadero gemeldet - am besten ganz offiziell über den sog. Bugtrucker?

Bei mir ist in einem großen Projekt XE2 so langsam, das praktisch keine vernünftige Arbeit möglich ist.
Den "Service" von Emb habe ich vor 3 Wochen per email angeschrieben, aber bisher keinerlei Reaktion.

Peter

[Delphi-Laie]

Zitat:

Zitat von hanspeter (Beitrag 1134471)

Zitat:

Zitat von Delphi-Laie (Beitrag 1134457)

Wurde der Fehler denn Embarcadero gemeldet - am besten ganz offiziell über den sog. Bugtrucker?

Bei mir ist in einem großen Projekt XE2 so langsam, das praktisch keine vernünftige Arbeit möglich ist.
Den "Service" von Emb habe ich vor 3 Wochen per email angeschrieben, aber bisher keinerlei Reaktion.

Peter

Verstehe ich nicht. Jetzt, wo ein aktuelles Produkt ausgeliefert wurde, kann es doch gar nichts wichtigeres als die berühmt-berüchtigte Nachbesserung für diesen Softwarehersteller geben. Oder sind gefühlt-geschätzte 95-98% aller Emba-Programmierer schon wieder mit XE3 beschäftigt?

Wenn ich die zahllosen Beanstandungen in den Foren mir zu resumieren erlaube: Das RAD-Studio XE2 hat m.E. die Bezeichnung "Bugware" verdient (nein, die stammt nicht von einem Bäcker).

[squetk]

Neue Erkenntnisse zum Thema "Code Insight in XE2-IDE quälend langsam":

In diesem Post https://forums.embarcadero.com/threa...threadID=61875 steht geschrieben, dass die Geschwindigkeit von Code Insight stark von der Anzahl der in der IDE geöffneten Units abhängt.
Ich habe nun leider immer eine Masse Units gleichzeitig geöffnet :oops: - nachdem ich bis auf eine alle geschlossen habe, ist die Dauer bis zur Anzeige auf erträgliche 1-2 Sekunden geschrumpft.

Damit lässt es sich jetzt mit XE2 arbeiten! :-D

[himitsu]

Witzig ist ja, das mindestens die aktuelle Unit, bei nahezu jedem einzelnen getippten Buchstaben im Hintergrund durch den Compiler gejagt wird, was etwas Zeit frißt.

Bleibt dennoch der Bug, daß es bei vielen offnen Dateien länger braucht, obwohl es ja eigentlich nicht langsamer werden dürfte sollte. :wall:

[smudo]

Vielleicht bin ich ja etwas anspruchsvoll, aber ich finde selbst 1-2 Sekunden störend.
Solche Verzögerungen kenne ich von Delphi 2009 nicht, geschweige denn vom guten alten Delphi 7

Grüße aus der Tagschicht :cyclops:

[Uwe Raabe]

Zitat:

Zitat von squetk (Beitrag 1136220)

ist die Dauer bis zur Anzeige auf erträgliche 1-2 Sekunden geschrumpft.

Wie ist denn in den Optionen für Code-Insight die Verzögerung eingestellt?

[jbg]

Von wie vielen offenen Dateien sprecht ihr hier? Sind dass alles Dateien aus dem aktiven Projekt, oder Dateien aus mehreren Projekten in der Projektgruppe? Sind es hauptsächlich Formulare/Frames/Datenmodule oder einfache Units?

[himitsu]

Mit vielen Dateien hab ich hier selber kaum Probleme. (sind manchmal schon 10-20 und im Durchschnitt vielleicht 2-8 Units mit und ohne Forms, in verschiedenen Packages/DLLs/EXEn)

Aber in der Darstellung ist die Delphi-IDE echt schlimm ... via RDP merkt man es deutlich, daß sich manche Teie tausende Male neu zeichnen ... vorallem wenn man sich wieder einloggt.

[squetk]

Also ich hatte so ca. 30 Units offen, aller Art (Formulare und einfache Units).
In der Projektgruppe gibt es drei Projekte, aus allen dreien waren Units offen.

Ich werde mal testen, ob geöffnete Forms oder Units aus anderen Projekten bremsen.

Die Automatik für Code Insight war aus, ich hatte es mit Tastenkombinationen aufgerufen.
Ich habe sie jetzt eingeschalten und es läuft zufriedenstellend.

[jbg]

Ist AQTime installiert? Wenn ja, wird CodeInsight schneller, wenn es nicht von der IDE geladen wird? Ich habe da so einen Verdacht, dass sich ein Plugin etwas tief vergraben hat.

UPDATE:
Ich habe den Auslöser gefunden. Wenn man die "Embarcadero LiveBindings Components" (3 Packages) deinstalliert, wird gleich alles viel schneller: Umschalten von Code=>Design=>Code, CodeInsight kommt schneller.

[squetk]

:thumb:
Stimmt! Ich habe die drei mal rausgeworfen und jetzt ist die IDE genauso schnell wie die auf dem selben Rechner installierten Delphi 2009 und XE!
Selbst wenn viele Units offen sind.

Besten Dank!

Stellt sich nur die Frage, ob wir nun auf Dauer auf die LiveBindings verzichten müssen.

[Delphi-Laie]

Zitat:

Zitat von jbg (Beitrag 1136385)

UPDATE:
Ich habe den Auslöser gefunden. Wenn man die "Embarcadero LiveBindings Components" (3 Packages) deinstalliert, wird gleich alles viel schneller: Umschalten von Code=>Design=>Code, CodeInsight kommt schneller.

Ich litt zwar nicht an dieser Langsamkeit, weil ich XE2 bisher nur zum Compilieren schon fertiger Projekte benutzte, aber dennoch auch von mir große Anerkennung und Dank für diesen Spürsinn und den Erfolg!

Wofür man diese "LiveBindings" benötigt (oder wofür nicht), möchte ich jetzt nicht hier erfragen (das läßt sich über Suchfunktionen finden), jedoch etwas anderes: Könnte es sein, daß (auch) diese "LiveBindings" fehlerhaft sind? Also, daß sie CodeInsight bis zur (Un-)Zumutung verlangsamen, ist sicher nicht beabsichtigtes Ziel und wurde sicher nicht vorsätzlich dort hineinprogrammiert.

Falls ja: Sollte man diesen Fehler (nicht) Embarcadero melden?

[smudo]

Wow, das würd ich ja mal fast als vollen Erfolg werten, wenn die Livebindings nicht gerade einer der Gründe für den Kauf von XE2 gewesen wären :?

Trotzdem einen riesen Dank an jbg und natürlich an squetk, der das ganze Thema ins Rollen brachte. :thumb:

[Daniel]

Das macht doch hoffnungsvoll, dass die Ursache oder eine der Ursachen jetzt identifiziert ist. Das sollte uns einem Patch durch EMBT oder andere *g* einen großen Schritt näher gebracht haben.

Vielen Dank, Andreas für die Analyse. :-)

[Stevie]

Zitat:

Zitat von jbg (Beitrag 1136385)

Ich habe den Auslöser gefunden. Wenn man die "Embarcadero LiveBindings Components" (3 Packages) deinstalliert, wird gleich alles viel schneller: Umschalten von Code=>Design=>Code, CodeInsight kommt schneller.

Bei dieser News konnte ich mir zugegebenermaßen ein hämisches Lachen nicht verkneifen ;)

[jbg]

Zitat:

Zitat von Daniel (Beitrag 1136425)

Das sollte uns einem Patch durch EMBT oder andere *g* einen großen Schritt näher gebracht haben.

Warum habe ich das Gefühl, dass den Bug mal wieder ich beheben muss und dass es sehr wahrscheinlich ist, dass der "Fix" nicht in den IDE Code einfließen wird. Wie kann man eigentlich so einen Schrott programmieren (oder ich lese das falsch heraus), aber anstatt dass die IDE weiß wie alle geladenen Dateien heißen, muss sie das per "ModuleIs()" an jeder Datei nachfragen. Und ModuleIs() wird von mehreren Klassen unterschiedlich implementiert. Eine Optimierung ist da schier unmöglich. Nichtsdestotrotz habe ich jetzt eine Lösung gefunden. Nur ist die leider sowas von unsauber: Zwei mal mehrere Listen wegkopieren und beim erneuten "mod 2" Aufruf die neuen Listen mit den alten vergleichen und dann das Ergebnis des letzten Aufrufs per Callback-Funktion zurückgeben. Gefällt mir nicht, funktioniert aber anscheinend sehr gut.

Leider ist mir beim Testen gleich der nächste Bug aufgefallen. Wenn man mehrere Dateien offen hat und zusätzlich noch eine Menge Projekte in der Projektgruppe hat, dann wird der Editor richtig langsam und man kann den Buchstaben einzeln zuschauen wie sie auftauchen. Der Grund: Bei jedem Tastendruck (außer Navigationstasten) wird das TabControl neugezeichnet. Und die IDE-TabControl Komponente ist so blöd und holt sich per Event-Handler den ImageIndex für jede offene Datei (auch wenn die gar nicht im sichtbaren Bereich sind). Das wiederum durchläuft so einige Schleifen. Ich tippe auf "Offene Dateien".Count * "Dateien in Projekten".Count im gesamten.

Meine Kollegen "nerven" mich schon mit, "wann schreibst du eigentlich mal eine eigene IDE". Irgendwann werde ich sicherlich zu dem Punkt kommen (wenn da nicht so viel zu tun wäre) [nein, Lazarus fasse ich nicht an]

[himitsu]

Wäre schön, wenn du in deiner IDE dann eine schnucklige OTA verbaust, damit wir dann für dich Buxfixes schreiben könne, ohne rumhacken zu müssen. :angle:

[QuickAndDirty]

jbg bist du eigentlich zu teuer, dass man dich nicht zum entfernen solcher Fehler im Originalsource beschäftigen/Anheuern/was_auch_immer kann?

Oder bist du zu billig, weil der Fix ja eh Gratis kommt?

[mquadrat]

Das Unangenehme für Emba dürfte jetzt sein, dass sie entweder alles lassen wie es ist - funktionierend aber langsam - oder im Core rumbasteln mit der Gefahr, dass es danach nicht mehr in allen Situationen funktioniert.

Decisions, decisions..

[squetk]

Aber die werden doch mit Unit-Tests arbeiten?

[daywalker9]

Sicherlich, aber alles abdecken können auch die nicht.

[Uwe Raabe]

Zitat:

Zitat von squetk (Beitrag 1136659)

Aber die werden doch mit Unit-Tests arbeiten?

Mit Unit-Tests kann man aber auch nur Fehler abfangen, von denen man weiß, daß sie vorkommen können.