Delphi 10.1 Berlin - IDE Geschwindigkeit bei visueller Vererbung

[Bambini]

Bei dem Versuch eines Umstiegs von DX10 auf DX10.1 sind die IDE Reaktionszeiten beim Laden einer TForm mit visueller Vererbung sehr langsam geworden. In einem großen VCL Projekt dauerte z.B. das Öffnen einer Form mit visueller Vererbung in DX10 Seattle ca. 1-2 Sekunden. Bei DX10.1 Berlin dauert auf der gleichen Maschine mit dem gleichen Code, die gleiche Form jetzt ca. 15-18 Sekunden. Weder ein schließen und wieder öffnen der Form oder auch wenn ich alle inherited Form zuvor geöffnet habe, bringt eine zeitliche Änderung.
In diesem Zustand ist DX10.1 Berlin leider nicht zu gebrauchen.

Ist dazu etwas bekannt?

[Bambini]

Habe mal versucht in den CallStack der BDE.exe zu schauen was da so los ist.
Dabei fällt auf, obwohl das ein reines VCL Projekt ist, das hier auch FMX Bibliotheken (bindcompfmx240.bpl) aktiv sind:

Delphi-Quellcode:

rtl240.bpl!@System@Generics@Collections@%TStack__1$i%@TEnumerator@MoveNext$qqrv+0x3ee
rtl240.bpl!@System@Classes@InvalidPoint$qqrx24System@Types@TSmallPoint+0x4d40
rtl240.bpl!@System@Generics@Collections@%TStack__1$i%@TEnumerator@MoveNext$qqrv+0x3ee
rtl240.bpl!@System@Generics@Collections@%TStack__1$i%@TEnumerator@MoveNext$qqrv+0xd05
rtl240.bpl!@System@Classes@InvalidPoint$qqrx24System@Types@TSmallPoint+0x4d40
rtl240.bpl!@System@Classes@InvalidPoint$qqrx24System@Types@TSmallPoint+0x5544
rtl240.bpl!@System@Classes@GetClass$qqrx20System@UnicodeString+0x2e
bindcompfmx240.bpl!@System@Generics@Collections@%TList__1$46Data@Bind@Dblinks@TDBGridLinkColumnDescription%@TEnumerator@MoveNext$qqrv+0x5045
bindcompfmx240.bpl!@System@Generics@Collections@%TList__1$46Data@Bind@Dblinks@TDBGridLinkColumnDescription%@TEnumerator@MoveNext$qqrv+0x7fe7
bindcompfmx240.bpl!@System@Generics@Collections@%TList__1$46Data@Bind@Dblinks@TDBGridLinkColumnDescription%@TEnumerator@MoveNext$qqrv+0x7ebf
rtl240.bpl!@System@@IntfCopy$qqrr44System@%DelphiInterface$17System@IInterface%x44System@%DelphiInterface$17System@IInterface%+0xc

[Bambini]

Noch ein kleiner Nachtrag:
Benennt man diese bindcompfmx240.bpl um und ignoriert die Delphi Meldungen beim Start, sind die Geschwindigkeiten beim Öffnen der Formulare hervorragend.

[Der schöne Günther]

Machst du einen Eintrag im Bugtracker? :-)

[Uwe Raabe]

Könnte an QC 116169 und dem fehlenden IDE-Fixpack für Berlin liegen.

[madas]

Zitat:

Zitat von Uwe Raabe (Beitrag 1336663)

Könnte an QC 116169 und dem fehlenden IDE-Fixpack für Berlin liegen.

Leider sprechen die Kommentare im QC für sich und gegen Delphi. :(
Seit 7 Major Versionen nicht gefixt. Hut ab.

[Bambini]

Delphi 10 Seattle ist mit oder ohne IDE-Fixpack beim Öffnen der Form schnell. Es macht in diesem Punkt keinen Unterschied.

Ich habe dunkel im Hinterkopf, das Andreas Hausladen mal gesagt hatte, das er für die neueren IDE keine Fixes mehr erstellt, da er diese selbst nicht mehr nutzt und die IDE ausschließlich für die Fixes kaufen müsste und das zu teuer ist.

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1336663)

Könnte an QC 116169 und dem fehlenden IDE-Fixpack für Berlin liegen.

Vermute das ist nicht mein Problem, da ich Livebinding nicht verwende.

[madas]

Zitat:

Zitat von Bambini (Beitrag 1336679)

Zitat:

Zitat von Uwe Raabe (Beitrag 1336663)

Könnte an QC 116169 und dem fehlenden IDE-Fixpack für Berlin liegen.

Vermute das ist nicht mein Problem, da ich Livebinding nicht verwende.

Laut QC reicht es ja schon aus, wenn die Packages im Paketmanager angehakelt, sprich enabled, sind, um alles langsamer zu machen. Unabhängig davon, ob diese nun im Projekt wirklich Verwendung finden oder nicht. Also Haken bei

Zitat:

Zitat von http://qc.embarcadero.com/wc/qcmain.aspx?d=116169

- Embarcadero LiveBindings Components
- Embarcadero LiveBindings Components FireMonkey
- Embarcadero LiveBindings Components VCL

raus und schauen, ob sich eine Besserung einstellt.

[win568]

Es ist leider umso Bestürzender festzustellen, dass bis dato die IDEFix Packs notwendig sind.
Andreas hat alle seine Änderungen öffentlich gemacht. Wie verblendet muss man sein, dass man
Fehler, die bereits so lange in der IDE vorhanden sind, nicht fixt.

Weiters ist es seitens Emba traurig, dass Andreas nicht gratis jede Delphi Version bekommt,
damit er wieder die Fehler in der IDE fixen kann.

[Bambini]

Zitat:

Zitat von madas (Beitrag 1336683)

Also Haken bei

Zitat:

Zitat von http://qc.embarcadero.com/wc/qcmain.aspx?d=116169

- Embarcadero LiveBindings Components
- Embarcadero LiveBindings Components FireMonkey
- Embarcadero LiveBindings Components VCL

raus und schauen, ob sich eine Besserung einstellt.

Damit klappt's. Mit den ausgeschalteten Livebindings lassen sich die Forms alle wieder schnell öffnen.
Auch unter DX10 Seattle geht's ohne diese Lib's schneller.

[Der schöne Günther]

Bei mir ist grundsätzlich jedes Formular und jeder Frame von einer eigenen Basisklasse abgeleitet, und ich habe das LiveBindings-Fenster immer an.

Ich fange zwar grade erst an, mit Seattle warm zu werden, konnte aber bis heute keine solche Probleme feststellen. Wie kann ich das mit Berlin reproduzieren? Einfach Formular von einem ableiten und dann? :|

[Bambini]

Zitat:

Zitat von Der schöne Günther (Beitrag 1336713)

Bei mir ist grundsätzlich jedes Formular und jeder Frame von einer eigenen Basisklasse abgeleitet, und ich habe das LiveBindings-Fenster immer an.

Ich fange zwar grade erst an, mit Seattle warm zu werden, konnte aber bis heute keine solche Probleme feststellen. Wie kann ich das mit Berlin reproduzieren? Einfach Formular von einem ableiten und dann? :|

Das leider ist nicht so einfach isoliert darzustellen.
Ich verwende ausgiebig die DevExpress Komponenten und es sieht so aus das Berlin mit den Livebindings und DevExpress ein Problem hat.
Ich gebe ein Beispiel an den Support von DevExpress weiter. Mal hören, was die sagen.

[Bambini]

Zitat:

Zitat von Bambini (Beitrag 1336717)

Zitat:

Zitat von Der schöne Günther (Beitrag 1336713)

Bei mir ist grundsätzlich jedes Formular und jeder Frame von einer eigenen Basisklasse abgeleitet, und ich habe das LiveBindings-Fenster immer an.

Ich fange zwar grade erst an, mit Seattle warm zu werden, konnte aber bis heute keine solche Probleme feststellen. Wie kann ich das mit Berlin reproduzieren? Einfach Formular von einem ableiten und dann? :|

Das leider ist nicht so einfach isoliert darzustellen.
Ich verwende ausgiebig die DevExpress Komponenten und es sieht so aus das Berlin mit den Livebindings und DevExpress ein Problem hat.
Ich gebe ein Beispiel an den Support von DevExpress weiter. Mal hören, was die sagen.

DevExpress kann das Problem nachstellen aber leider nicht beheben.
Damit wird der Umstieg auf Berlin für dieses Projekt erst einmal zurückgestellt.

[Uwe Raabe]

Zitat:

Zitat von Bambini (Beitrag 1339254)

DevExpress kann das Problem nachstellen aber leider nicht beheben.

Können die denn wenigstens was zu der Ursache sagen?

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339257)

Zitat:

Zitat von Bambini (Beitrag 1339254)

DevExpress kann das Problem nachstellen aber leider nicht beheben.

Können die denn wenigstens was zu der Ursache sagen?

Nein, bisher nicht:
https://www.devexpress.com/Support/C...etails/T372303

[Uwe Raabe]

Lese ich das richtig? Du speicherst nicht alle Änderungen vor dem Compilieren? Das ist bei mir das Erste, was ich nach einer Neuinstallation der IDE aktiviere.

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339261)

Lese ich das richtig? Du speicherst nicht alle Änderungen vor dem Compilieren? Das ist bei mir das Erste, was ich nach einer Neuinstallation der IDE aktiviere.

Ist sehr komfortabel das ich nicht jede kleine Änderung in die _history wandert, sondern nur die gewollten.
Das hat bisher in jeder Delphi IDE problemlos funktioniert.

[jaenicke]

Das heißt aber auch, dass du alle Änderungen verlierst, wenn die IDE abstürzt und du größere Änderungen (ggf. aus Versehen) nicht gespeichert hast...

Wirklich relevant ist als History doch eh nur die des Git/Mercurial/... Repositorys.

Das Formular vorher schließen zu müssen, ist aber auch nicht sonderlich angenehm.

[Daniel]

Zitat:

Zitat von jaenicke (Beitrag 1339265)

Das heißt aber auch, dass du alle Änderungen verlierst, wenn die IDE abstürzt und du größere Änderungen (ggf. aus Versehen) nicht gespeichert hast...

Ohne Zweifel wird sich jeder Entwickler dessen bewusst sein, sobald die IDE das erste Mal abgestürzt ist. ;-)

Aber letztlich ist das Nutzungsverhalten des Fragestellers auch nicht Thema dieses Threads.

[Bambini]

Zitat:

Zitat von Daniel (Beitrag 1339267)

Zitat:

Zitat von jaenicke (Beitrag 1339265)

Das heißt aber auch, dass du alle Änderungen verlierst, wenn die IDE abstürzt und du größere Änderungen (ggf. aus Versehen) nicht gespeichert hast...

Ohne Zweifel wird sich jeder Entwickler dessen bewusst sein, sobald die IDE das erste Mal abgestürzt ist. ;-

Dazu gibt es es doch die neue Option in der IDE: [Tools][Optionen][Umgebungsoptionen][Auto-Wiederherstellung]

[Bambini]

Zitat:

Zitat von jaenicke (Beitrag 1339265)

Wirklich relevant ist als History doch eh nur die des Git/Mercurial/... Repositorys.

Dorthin wandern nur gewünschte Änderungen, keine F9 Zwischenstände.

[jaenicke]

Eben drum ;-)

Deshalb interessieren mich auf dem History Tab auch normalerweise die Revisionen und nicht die F9 Speicherungen.

Jedenfalls wäre der Workaround dann möglich, eine echte Lösung wird ja kaum schnell da sein.

[Bambini]

Kleines Update zu diesem BUG:
Auch das Update 1 von Delphi 10.1 Berlin behebt das Problem nicht :cry:

[jaenicke]

Dazu gibt es hier übrigens noch einen Vorgang, der bei Update 1 drin steht. Da der Status "cannot reproduce" ist, weiß ich aber nicht so recht warum.
https://quality.embarcadero.com/browse/RSP-14796

Ich würde dazu raten dort entsprechend zu kommentieren, wenn das Problem weiterhin besteht...

[Bambini]

Zitat:

Zitat von jaenicke (Beitrag 1348088)

Dazu gibt es hier übrigens noch einen Vorgang, der bei Update 1 drin steht. Da der Status "cannot reproduce" ist, weiß ich aber nicht so recht warum.
https://quality.embarcadero.com/browse/RSP-14796

Ich würde dazu raten dort entsprechend zu kommentieren, wenn das Problem weiterhin besteht...

Bin mir nicht sicher ob das die gleichen Ursachen hat.

Wenn man aber mal schaut, das selbst solche "einfachen" Bugs wie das Code-Inside Problem vom Uwe, es nicht in das Update 1 geschafft haben
https://quality.embarcadero.com/browse/RSP-14914
habe ich sehr wenig Hoffnung, dass mein Corner-Case Problem jemals behoben wird.