D2010/XE Formdesigner langsam

[SvB]

Ich habe folgendes Problem. Ein Formular mit ca. 100 Komponenten/Controls schalte ich mit F12 zwischen den Codeansicht und der Designansicht um. Bei Delphi 2007 geht das ohne Verzögerung. Von der Codeansicht zur Designansicht innerhalb einer Sekunde, ganz schnell.
Das Ganze mit dem selben Formular unter Delphi 2010 oder aktuell gerade getestet unter Delphi XE dauert ca. 5 Sekunden, d.h. von der Codeansicht zur Designansicht. Einige wenige Controls sind direkt sichtbar, nach ca. 5 Sekunden ist dann der Rest auch auf einen Schlag da. Die CPU-Aulastung geht in dieser Zeit auf fast 100% hoch. Das ist echt voll nervig und kostet unheimlich viel Zeit beim ständigen wechseln. Ich komme bei einem Projekt wirklich nicht gut voran unter D2010.
Hat jemand eine Ahnung ob das generell an D2010 (XE) liegt?

Zur Konfiguration: Alles ist auf dem selben PC in einer VM installiert, also jedes Delphi in seiner eigenen VM. Bei D2007 ist es XP Pro mit SP2 ohne Windowsupdates, Bei D2010 und XE ist es XP Pro mit SP3 und bis dato alle Windowsupdates. Könnte das vielleicht den Unterschied machen? Es ist sonst nichts anderes in der VM installiert. Jede VM hat eine CPU zugeordnet und 768MB RAM. Die VM-Dateien liegen auf der selben physichen Platte und es wird regelmäßig Defragmentiert, sowohl innerhalb der VM als auch auf der physichen Platte. In jedem Delphi sind die selben Komponenten installiert. Ich habe der D2010 VM auch schon mal 2 CPU zugewiesen, macht aber auch keinen Unterschied.
Der PC hat einen Core2 Extreme X9650 mit 3GHz und 6GB RAM (Windows 7 x64).

Vielen Dank für Eure Hilfe.

Gruß
Sven

[Uwe Raabe]

Don’t forget to disable the Component-Toolbar package

[SvB]

Danke, habs in D2010 entfernt, hat aber leider nichts gebracht. Gefühlsmäßig ist es vielleicht eine Sekunde schneller, aber immer noch zu langsam. Da kann man nicht gut mit arbeiten. Ist ist auch schon so, wenn ich ein Testprojekt erstelle mit zwei Komponenten (Button, Edit).
Werde mir jetzt mal noch die restlichen Komponenten in Delphi XE reininstallieren und dann noch mal testen. Ich melde mich dann wieder.

Danke
Sven

[himitsu]

Und dabei hat man doch diese Toolbar extra wieder eingebaut, weil sie alle haben wollten,
da kann man sie doch nicht einfach abschalten? :cry:

Es könnte natürlich auch noch an was Anderem, wie .net oder sonstwas liegen, welches auf diesem PC nicht richtig läuft. :gruebel:

Ist denn nur dieses Umschalten so langsam?

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1047126)

Es könnte natürlich auch noch an was Anderem, wie .net oder sonstwas liegen, welches auf diesem PC nicht richtig läuft. :gruebel:

.NET hat beim beim Umschlaten seine Finger nicht im Spiel. Muss also was anderes sein.

[himitsu]

Keine Ahnung wo das mitspielt ... ist schon sehr interessant, das für meine nativen Delphi-Programme die IDE damit quasi verseucht sein muß.

Nja, ich wollt nur Andeuten, daß es auch an seinem PC, installierten Fremdkomponenten/zusatzmodulen oder halt an etwas Anderem liegen könnte.
Mir kommt das Umschalten jedenfalls nicht langsam vor und auch bei größeren (überladenen) Forumlaren hab ich nicht daß Gefühl, daß es viel langsamer ist, als damals in D7.
OK, der Rechner ist inzwischen schneller, aber 5 Sekunden kann ich nicht erzeugen.

[divBy0]

Das ist mir unter 2010 auch noch nicht aufgefallen... Ich habe zwar keine 100 Controls, aber bei einem Projekt gibt es eine Form mit fast 50, das umschalten geht eigentlich direkt.

[blackfin]

Mal ein ganz simpler Vorschlag: Neuesten Grafikkarten-Treiber installiert / mal versucht neu zu installieren?
Solche besagten Fenster-Lags hatte ich damit schon ein paar mal lösen können (jetzt aber nicht speziell Delphi betreffend).

[SvB]

So, unter D2010 wirds einfach nicht schneller, deshalb habe ich mich heute Abend mal ein wenig mehr mit Delphi XE beschäftigt. Wie ich schon zu Anfang festgestellt habe, war direkt nach der Installation eine kleine Verzögerung beim Umschalten festzustellen. Jetzt habe ich mal noch eine Komponenten installiert (Toolbar2000, SpTBX, Absolute Database, Zipforge, JCL und JVCL und noch LMD VCL-Complete). Danach war noch eine deutlich größere Verzögerung spürbar und ich habe noch lange nicht alle Komponenten installiert. Also je mehr Komponenten ich da mir rein nehme, um so länger dauert es. Mit D2007 habe ich das Problem nicht, da sind die selben Komponenten installiert, halt nur die D2007 Version. Wenn ich D2007 unten mit den Tabs mittels Maus umschalte, dann ist das Formular schon fertig aufgebaut, bevor ich die Maustaste losgelassen habe. Ich habe z.B. auch festgestellt, wenn ich z.B. in Tools/Optionen bin, den Dialog ohne irgendwelche Änderungen wieder schließe, dann braucht mein Formular auch 3-4 Sekunden bis es sich wieder aktualisiert hat.

Ich werde mal noch weitere Tests machen.

So und jetzt noch zu Euren anderen Fragen:
Wie schon gesagt, ich arbeite mit Delphi immer nur in VM's. Für jede IDE eine eigene VM und ohne großartig Software. Jetzt aktuell mit Delphi XE habe ich mir wieder eine neu VM mit Windows XP Pro SP3 installiert, dann alle Windows Updates gefahren und alles was .NET über Windows Updates zu bieten hatte. Dann Delphi XE installiert und die Komponenten eingebunden. Es ist kein Antivirus installiert und auch sonst keine Software.
Betreffs Grafiktreiber, ich habe die aktuellen VMWare-Tools im Gast installiert, dass kann also das Problem nicht sein.
Ich habe zwei 24" Monitore am Rechner angeschlossen, auf der einen Seite läuft die VM mit D2007, auf der anderen Seite die VM mit D2010. In jedem Delphi (VM) ist das selbe Formular geladen. In D2007 ohne Verzögerung, in D2010 ca. 4-5 Sekunden Verzögerung.

Gruß
Sven

[SvB]

Weitere Test durchgeführt, mann da gehen Stunden drauf und mein Kopf qualmt schon.

Zu erst habe ich ein WXP mit integriertem SP2 in einer VM installiert ohne weitere Updates, dann D2010. Das selbe Ergebnis, Verzögerungen beim Umschalten zwischen Code und Formular. Irgendwelche Windows Updates oder selbst das SP3 kann man da als Ursache ausschließen. Es könnte höchstens an den Softwarevoraussetzungen für Delphi liegen, .NET 3.5 SP1, Visual J# 2.0, kann ich ja leider nicht ohne probieren.

Ich habe das Problem zwar nicht gefunden, aber eine Lösung! Ich habe jetzt mal testweise in einer VM W7x64 installiert, ohne Updates. Dann D2010 und siehe da, das rennt wie Schmitts-Katze. Ich habe die selben Hardware-Voraussetzungen definiert wie bei WXP (1CPU mit 1 Kern, aber etwas mehr speicher als bei XP). Kann mir das jetzt mal einer erklären?

Von mir aus nehme ich auch Windows 7, aber mit XP wäre es mir lieber gewesen, braucht nicht so viel Speicher.

Dann werde ich mal alle Komponenten installieren und Bescheid geben wie es läuft.

Gruß
Sven

[quantum]

Es könnte auch sein, dass nur eine oder mehrere Komponenten dieses Problem verursachen.
Schonmal Komponente nach Komponente vom Forular gelöscht und auf Zeitunterschied beim umschalten geprüft?

[jbg]

In einem solchen Fall würde ich Delphi mit Delphi starten und dann wenn die Wartezeit eintritt, mit F12 (Breakpoint-Taste) unterbrechen, in der Debuggenden-IDE auf den Mainthread wechseln und im Call-Stack nachschauen, was da los ist.

[SvB]

So, ich habe das Problem gefunden. Ich habe bisher immer das RAD Studio 2010 inkl. dem eingebauten Update 1-5 vom 14.12.2009 installiert. Habe ich jetzt von der Test-XP VM wieder deinstalliert und habe dann die erste Version, die raus gekommen ist, installiert. Funktionert alles wunderbar. Das Problem tritt erst dann auf, wenn das Update 4 installiert ist. Irgend etwas wurde da geändert, was das Problem verursacht. In Delphi XE ist das dann schon direkt eingebaut.
Das Update 1 hatte ich vorher auch noch installiert, da war das Problem noch nicht, das Update 2 und 3 habe ich nicht mehr separat gehabt und ist auch nicht mehr zum download verfügbar, deshalb habe ich direkt Update 4 installiert, in dem alle vorherigen Updates enthalten sind. In der Readme zum Update 4 steht leider nicht, was sich alles geändert hat, mal schauen, ob dírgendeine Info darüber finde.

@quantum: Die Verzögerung tritt schon auf, wenn nur ein einzelner TButton auf der Form ist und die Verzögerung wird um so länger je mehr Komponenten installiert sind. Wie gesagt, es reicht dann auch nur ein einzelner TButton.

@jbg: Ich denke, dass ich nicht genug Ahnung davon habe, dann auf dem Callstack nachzuschauen. Da wird dann doch nur ASM angezeigt, oder?

Jetzt muss ich mir erst mal überlegen wie ich weiter mache. Ich werde vielleicht testweise mal noch ein XP direkt auf einer Hardware installieren und schauen wie es sich da verhält. Vielleicht ist es ein Problem, was in Verbindung mit einer VM auftritt, was ich allerdings nicht glaube, da es ja definitiv nach einem Update von Delphi auftritt.

Wenn jemand noch eine Idee hat, was ich jetzt tun kann, nur zu, bin für alles offen. Hat denn jemand D2010 mit allen Updates noch auf einem XP laufen?

Gruß und Gute Nacht
Sven

[himitsu]

Du hast die fehlerhaften Updates 2 und 3 mit intalliert?

[SvB]

Was meinst Du mit fehlerhaften Updates? Ich habe bei mir das Update 1 vom 22.09.2009 und dann das UpdatePack vom Dez. 2009 auf der Platte. Habe zu erst das Update 1 installiert, da geht noch alles. Dann habe ich das Update 4 auf dem UpdatePack installiert und dann treten die Probleme auf. Im Update 4 sind ja alle vorherigen Updates integriert. Ist das Update 4 auch fehlerhaft, bzw. die darin enthalten Updates 2 und 3 dann immer noch?

[himitsu]

OK, darum fragte ich ja, also ob du diese auch noch mit installiert hattest, wegen dem "1-5".
Die Updates 2 und 3 von D2009/D2010 waren fehlerhaft und wurden durch die fehlerbereinigten Updates 4 und 5 ersetzt.
Somit sind also nur noch die Updates 4, 5 und die beiden HelpUpdates von Nöten.

Zitat:

Zitat von jbg (Beitrag 1047522)

In einem solchen Fall würde ich Delphi mit Delphi starten und dann wenn die Wartezeit eintritt, mit F12 (Breakpoint-Taste) unterbrechen, in der Debuggenden-IDE auf den Mainthread wechseln und im Call-Stack nachschauen, was da los ist.

Am Besten du probierst dieses mal aus und schaust wo es hängt.

[SvB]

Alles klar, ich habe mir mal mit dem Debugging versucht.

Sobald ich F12 drücke, dann wird in die debuggende IDE gewechselt und wenn ich dort den "Main IDE Thread" anwähle wird im Aufruf Stack folgendes angezeigt:

:7c91eb94 ntdll.KiFastSystemCallRet
:7c91e21f ntdll.NtQueryVirtualMemory + 0xc
:7c922cb7 ntdll.LdrAccessResource + 0x15
:7c922cb7 ntdll.LdrAccessResource + 0x15
:77d19c4e USER32.LoadStringW + 0x18
:500116da rtl140.@System@LoadResString$qqrp20System@TResStri ngRec + 0x4a
:20925bd5 ; C:\Programme\Embarcadero\RAD Studio\7.0\bin\coreide140.bpl
:2091eff8 coreide140.@Toolfrm@TToolForm@ItemAdded$qqrx55Syst em@%DelphiInterface$t27Paletteapi@IOTAPaletteGroup %x58System@%DelphiInterface$t30Paletteapi@IOTABase PaletteItem% + 0x80
:2091dd9c ; C:\Programme\Embarcadero\RAD Studio\7.0\bin\coreide140.bpl
:2091eec6 coreide140.@Toolfrm@TToolForm@EndUpdate$qqrv + 0x6e
:2091eec6 coreide140.@Toolfrm@TToolForm@EndUpdate$qqrv + 0x6e
:2085751a coreide140.@Editorform@TEditWindow@EndViewSelect$q qrv + 0x12
:2085207b coreide140.@Editorform@TEditWindow@ViewBarChange$q qrp14System@TObjectiro + 0x23
:50328fa7 vcl140.@Tabs@TTabSet@CanChange$qqri + 0x23
:208ca1ef coreide140.@Editorbuffer@TEditSource@SwitchToView$ qqrx20System@UnicodeString + 0x5f
:00000006

Leider kann ich selbst damit nicht viel mit anfangen.

Gruß
Sven

[jbg]

Zitat:

Zitat von SvB (Beitrag 1047592)

Leider kann ich selbst damit nicht viel mit anfangen.

Aber ich kann.
Könntest du das noch zweimal wiederholen (noch 2 Call-Stacks), damit ich sicher sein kann, dass es sich um ein exzessives Ressource-String-Abfragen handelt.

[SvB]

Ich habe jetzt noch ein paar mal mit F12 hin und her geschaltet und hier der CallStack:

:7c91eb94 ntdll.KiFastSystemCallRet
:7c91e21f ntdll.NtQueryVirtualMemory + 0xc
:7c922cb7 ntdll.LdrAccessResource + 0x15
:77d19bc9 USER32.LoadCursorW + 0x60
:77d19c4e USER32.LoadStringW + 0x18
:500116da rtl140.@System@LoadResString$qqrp20System@TResStri ngRec + 0x4a
:20925bd5 ; C:\Programme\Embarcadero\RAD Studio\7.0\bin\coreide140.bpl
:2091eff8 coreide140.@Toolfrm@TToolForm@ItemAdded$qqrx55Syst em@%DelphiInterface$t27Paletteapi@IOTAPaletteGroup %x58System@%DelphiInterface$t30Paletteapi@IOTABase PaletteItem% + 0x80
:2091dd9c ; C:\Programme\Embarcadero\RAD Studio\7.0\bin\coreide140.bpl
:2091eec6 coreide140.@Toolfrm@TToolForm@EndUpdate$qqrv + 0x6e
:20714546 coreide140.@Palmgr@TPaletteManager@EndUpdate$qqrv + 0xc6
:2085751a coreide140.@Editorform@TEditWindow@EndViewSelect$q qrv + 0x12
:2085207b coreide140.@Editorform@TEditWindow@ViewBarChange$q qrp14System@TObjectiro + 0x23
:50328fa7 vcl140.@Tabs@TTabSet@CanChange$qqri + 0x23
:208ca1ef coreide140.@Editorbuffer@TEditSource@SwitchToView$ qqrx20System@UnicodeString + 0x5f
:00000006

[jbg]

Dann liegt es wohl wirklich an System.LoadResString(). Mal schauen, ob ich das cachen kann.

[himitsu]

Die Frage ist auch/eher, warum muß in CanChange sooft ein ResourceString ausgelesen werden?

Im Prinzip könnte also doch eine der Fremdkomponenten dran Schuld sein, also z.B. wenn sie sich in die OTA einnistet.

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1047630)

Die Frage ist auch/eher, warum muß in CanChange sooft ein ResourceString ausgelesen werden?

Weil man den String eben unter "resourcestring" stehen hat. Da handelt man sich schnell unnötiges Resourcestring-Laden ein:

Delphi-Quellcode:

resourcestring
  RsMyString = 'Hallo Welt!';

var
  I: Integer;
  SL: TStrings;
begin
  // ...
  for I := 0 to 10000 do
    if SL[I] = RsMyString then ; // << bei jedem Durchlauf wird LoadResString(@RsMyString) aufgerufen
end;

[himitsu]

Hat Delphi denn keine Cache mehr, für "ResourceStrings" ?
Ich dachte Delphi ließt beim Programmstart alle ResourceStrings aus und speichert diese in einer Tabelle. :gruebel:.

[edit]
OK, hatte ganz vergessen, daß die IDE ja en nicht in Delphi programmiert wurde. :oops:

[edit2]
und grad nochma geguckt ... ich mar mir Recht sicher schonmal soeine Cache gehabt zu haben. :shock:

[jbg]

Hier gibt es ein IDE Fix Pack "special build", dass einen LoadResString-Cache einrichtet. (Delphi 2009, 2010 und XE).

http://andy.jgknet.de/fixpack/builds/

[SvB]

Cool jbg, Du bist der Held. Ich habe in meiner aktuellen Testumgebung ausprobiert und es sieht sehr gut aus. Dann habe ich in meiner Produktivumgebung getestet und mit dem besagten Formular verhält es sich jetzt so, wie ich es unter D2007 gewohnt war, bzw. wie es noch mit D2010 Update 1 funktioniert hatte. F12 drücken und das Formular ist da, so kann man vernünftig arbeiten.
Was bin ich Dir schuldig?

@himitsu: Man hat den Effekt auch schon, wenn man keine Fremdkomponenten installiert hat, einfach nur pures Delphi. Die Verzögerung ist dann zwar nicht so groß, aber man merkt es schon. Die Verzögerung wird um so länger, je mehr Fremdkomponenten installiert sind. Bei mit hatte es mit der Produktivumgebung mit vielen Fremdkomponenten ca. 4 Sek. gedauert, bis das Formular komplett aufgebaut war.

Jetzt mit der Anpassung von jbg flutscht das wieder.

Morgen werde ich dann mal in DXE testen.

[SvB]

Gerade das "Spezial IDEFixPack" unter Delphi XE getestet und es funktioniert! Super!

Gruß
Sven

[himitsu]

Insgesammt geht vieles im Formular schneller.
Das Einfügen/Kopieren von tausenden Objekten geht nun auch viel schneller. (auch wenn man es nie braucht.)

Ich weiß nicht was die machen, aber irgendwie scheint da einiges fast in exponentieller Geschwindigkeit langsamer zu werden, je menr Objekte es gibt.

[SvB]

Mir ist auch gerade noch was aufgefallen. Wenn ich z.B. in einer Actionliste oder in einer CollectionListe einer Komponete war, dann hat das auch diese Verzögerung lang gedauert bis man mal wieder etwas anders anklicken kann. Das ist jetzt auch weg.

[jbg]

Da muss ich das IDE Fix Pack ja bald in DelphiSpeedUp für 2009, 2010 und XE umbenennen. :lol:

[SvB]

Hi an alle,

kurzer Statusbericht: Ich hatte jetzt einige Tage mit Delphi 2010 und dem Fix gearbeitet und es war eine Wohltat. Ging wirklich alles viel flüssiger. Die letzte Woche bin ich mit meinem aktuellen Projekt auf Delphi XE umgezogen und es funktioniert auch sehr gut. Das Umschalten geht sehr schnell, so wie ich es unter D2007 gewohnt war.

Also, super Arbeit, das IDE-FixPack ist klasse.


Eine Frage habe ich noch: Ich arbeite gerne mit der Codevervollständigung. Nach jedem Kompilieren oder Starten der Anwendung mit F9 muss Delphi wohl immer wieder den ganzen Kram dafür neu einlesen und das dauert teilweise doch ganz schön lange und ist ziemlich nervig. Kann man da eventuell auch etwas machen?

[mkinzler]

Eigentlich wäre das primär eine Aufgabe von EM nicht von Andreas

[marcoX]

Dieses Problem tritt bei mir bei XE2 auf. Component-Toolbar package deaktivieren brachte keine Lösung. Irgendeine Idee? Die IDE-Fixes werden wohl kaum kompatibel sein.

[jbg]

Also vor den Delphi-Tagen wird das nix mit IDE Fix Pack für XE2. Zudem weiß ich noch nicht mal, welche Patches überhaupt noch notwendig sind, bzw. welche ich neu schreiben muss. Und so viel Zeit wie früher habe ich (im Moment) auch nicht mehr für meinen Tools.

[marcoX]

Zitat:

Zitat von jbg (Beitrag 1121939)

Also vor den Delphi-Tagen wird das nix mit IDE Fix Pack für XE2. Zudem weiß ich noch nicht mal, welche Patches überhaupt noch notwendig sind, bzw. welche ich neu schreiben muss. Und so viel Zeit wie früher habe ich (im Moment) auch nicht mehr für meinen Tools.

Dennoch: Meinen Respekt für die Arbeit!

Ich finde es ja immer wieder erschreckend, wenn Leute in ihrer freien Zeit "mal eben" Probleme beheben, die scheinbar Millionenkonzerne wie Embacadero oder früher Borland nicht fixen können - oder erst nach Jahren. Da fragt man sich, was die in diesen Konzernen den ganzen Tag so treiben. Meetings abhalten und Kaffee saufen? :D Man erinnere sich auch nur an Delphi SpeedUp und co...

[himitsu]

Die haben dir ja bestimmt immernoch keinen Einblick in die Sourcen gewährt?

Also um so erstaunlicher, daß er es schneller schafft sich von hinten reinzuhacken.

[marcoX]

Zitat:

Zitat von himitsu (Beitrag 1122108)

Die haben dir ja bestimmt immernoch keinen Einblick in die Sourcen gewährt?

Also um so erstaunlicher, daß er es schneller schafft sich von hinten reinzuhacken.

Das sind so dinge die ich als normalsterblicher nicht verstehe. Warum stellt man ihn nicht mit Kusshand und TOP Gehalt ein (notfalls Heimarbeit!)? Es käme doch allen zu Gute und die paar € würden Emba nicht weh tun.

[Jacques Murell]

Zitat:

Es käme doch allen zu Gute und die paar € würden Emba nicht weh tun.

Grundregel Nr. 1 der Softwareentwicklung: Erstelle niemals eine fehlerfreie Version - wenn du das perfekte Produkt ablieferst wird niemand mehr Folgeversionen kaufen. :D

[marcoX]

So, ich hab jetzt einen "Workaround" für das lahme umschalten zwischen Form+Code gefunden.

Und zwar, wenn ich vor dem Umschalten speichere, geht es SOFORT...die sekundenlange Verzögerung tritt nur bei einer ungespecherten Änderung auf... Kann sich darauf vllt. jemand einen Reim machen?