Zugriff auf Strings / Listen langsam?

[OlliWW]

Hallo,

Ich habe einen Fehler in meiner Software, aber ich komme nicht auf die richtige Lösung.

Die Software läuft auf verschiedenen Windows Systemen performant und ohne Probleme. Bei einigen Windows Server 2012 Systemen habe ich jedoch die Problematik, dass die gesamte Software langsamer reagiert. An der Hardware des Rechners kann es nicht liegen.

Ich konnte zwei "Ursachen" bereits eingrenzen:
1.) Man ist per RDP auf den Rechner verbunden = langsam. Ist man hingegen direkt auf der "Console", also sitzt vor dem PC verhält sich das System normal schnell
2.) Eine Methode die besonders auffällig ist ist "Combobox.Items.AddStrings(TStringList)"

Dieses Addstrings dauert bis zu 6 Sekunden, um eine Liste von ca. 50 Einträgen hinzuzufügen. Diese Methode ist natürlich abgesichert mit "BeginUpdate" und "EndUpdate".

Ich habe zwei Vermutungen:
Entweder werden Strings falsch behandelt / interpretiert oder es hat irgendwas mit den Visuellen Komponenten ansich zu tun. Hoffentlich habt ihr ein paar Tipps.

[Bernhard Geyer]

VCL oder FMX?

[OlliWW]

Vcl

[himitsu]

Der RDP hookt sich in die Grafikausgaben rein
und für die Dauer der Übertragung wird das Zeichnen somit ausgebremst.

Bei vielen Änderungen/großen Datenmängen bremst das natürlich enorm aus,
wobei hier nicht nur die Performance des Servers zählt, sondern auch die des Klienten und er Netzwerkverbindung.


Wenn ihr (viele) Daten in den Listen ändert, schaltet ihr dann auch die Ausgaben solange ab? (z.B. BeginUpdate)
Hängt vielleicht noch was am OnChange dran, was eventuell auch Ausgaben generiert?



Ich würde mir ja wünschen, wenn man im RDP sich die eintreffenden Daten anzeigen lassen könnte.
z.B. kürzlich geänderte Bereiche farblich markieren und natürlich Traffikstatistiken (Anzahl der Datenpackete und Datenmenge/Datenrate)

[OlliWW]

Hallo,

Ja wie oben bereits geschrieben machen wir ein Begin / EndeUpdate. Wie gesagt es ist ingesamt träge, allerdings besonders signifikant ist diese Stelle:

Delphi-Quellcode:

  with FontBox do
  begin
    Items.BeginUpdate;
    if meineForm <> nil then
    begin
      Items.AddStrings(meineForm.lstTTFonts);
    end;
    Items.EndUpdate;
  end; //with

Aufgrund der RDP Sache hatte ich auch zunächst auf das Zeichnen der Komponenten getippt, allerdings wird hier an dieser Stelle ja nicht wirklich gezeichnet und laut Profiler dauert das mit 50 Einträgen 6 Sekunden. Ich habe irgendwie im Bauchgefühl dass es irgendwas mit Strings (Unicode, Ansi...) zu tun haben könnte, bin mir aber nicht sicher.

[Sir Rufo]

AFAIK wird bei RDP der Inhalt der Controls (sofern Standard) übertragen und eben nicht die reine Anzeige.

Bei einem Edit wird eben der Typ (ein Edit) und die Eigenschaften übertragen, dadurch kann dieses Control dann am Ziel selber gezeichnet werden, was dann schneller ist, als dort ein Bild zu übertragen.

Nun, bei einem Listen-Control kann das natürlich dann wieder bremsen ;)

[OlliWW]

Zitat:

Zitat von Sir Rufo (Beitrag 1274451)

AFAIK wird bei RDP der Inhalt der Controls (sofern Standard) übertragen und eben nicht die reine Anzeige.

Das würde erklären, warum eine Teamviewer Verbindung auf diesem Rechner "schnell" ist. Die Frage ist:
Wie stelle ich das um?

Vielleicht noch eine interessante Sache:
Ich habe das Problem versucht lokal nach zustellen, indem ich auch einen Windows Server 2012 installiert habe. => Kein Erfolg, selbe Daten, selbe Version, es ist immer schnell. Installiert man bei dem Kunden Windows Server 2008R2 oder ähnliches ist es ebenfalls schnell. Nur 2012 mag nicht.

[OlliWW]

Ich habe eine andere "langsame" Stelle mit dem Profiler gemessen und am Ende war es auch hier:
Der Refresh einer Combobox.

Es scheint also ein Problem mit dem Zeichnen von Comoboboxen zu existieren. Irgendwelche Ideen? Ich habe eben ein "Tsaware" Flag gefunden, das man setzen kann, das hilft aber auch nicht.

[mjustin]

Zitat:

Zitat von OlliWW (Beitrag 1274452)

Zitat:

Zitat von Sir Rufo (Beitrag 1274451)

AFAIK wird bei RDP der Inhalt der Controls (sofern Standard) übertragen und eben nicht die reine Anzeige.

Das würde erklären, warum eine Teamviewer Verbindung auf diesem Rechner "schnell" ist. Die Frage ist:
Wie stelle ich das um?

Vielleicht noch eine interessante Sache:
Ich habe das Problem versucht lokal nach zustellen, indem ich auch einen Windows Server 2012 installiert habe. => Kein Erfolg, selbe Daten, selbe Version, es ist immer schnell. Installiert man bei dem Kunden Windows Server 2008R2 oder ähnliches ist es ebenfalls schnell. Nur 2012 mag nicht.

Was hat sich zwischen Windows Server 2008 R2 und 2012 denn geändert? ;)

Ich habe eher zufällig gelesen dass der DWM - Desktop Windows Manager) ab 2012 immer aktiviert ist und nicht abgeschaltet werden kann. Ist auf dem 2008 System der DWM in den Prozessen aufgeführt (in der RDP Sitzung)?

Wenn es am Betriebssystem liegt, muss das Problem überall auf 2012er RDP Umgebungen reproduzierbar sein. Ist es möglich eine kompilierte Testanwendung bereitzustellen?

Viele Grüße

[Bernhard Geyer]

Sind das eigentlich normale W2012-Server oder sind diese Citrix-Verseucht?
Habe schon öfter Problem gehabt die an Citrix lagen und durch Updates von Citrix behoben wurden.

[OlliWW]

Zitat:

Zitat von mjustin (Beitrag 1274500)

Wenn es am Betriebssystem liegt, muss das Problem überall auf 2012er RDP Umgebungen reproduzierbar sein. Ist es möglich eine kompilierte Testanwendung bereitzustellen?

Es ist komischerweise nicht reproduzierbar. In meinen Win2012 Testumgebungen funktioniert es tadelos, bei zwei von vier Kunden mit Win2012 nicht.
Leider kann ich keine Testanwendung bereitstellen, da dies eine sehr umfangreiche Anwendung ist.

Die Frage was sich zwischen Server 2008R2 und 2012 geändert hat ist denke ich sehr interessant. Auf jedenfall hat sich die RDP Version geändert.

Kein Citrix System.

Auf dem 2008R2 keine DWM.exe auf dem 2012 schon. Allerdings laufen auf allen anderen Betriebssystemen außer 2012 die Anwendungen performant da sind viele Terminalserver bei.

[mjustin]

Zitat:

Zitat von OlliWW (Beitrag 1274511)

Leider kann ich keine Testanwendung bereitstellen, da dies eine sehr umfangreiche Anwendung ist.

Ich hatte es so verstanden dass es - innerhalb der Anwendung - schon mit diesem Code auffallend lange Verarbeitungszeiten von mehreren Sekunden bei 50 Einträgen gibt:

Delphi-Quellcode:

  with FontBox do
  begin
    Items.BeginUpdate;
    if meineForm <> nil then
    begin
      Items.AddStrings(meineForm.lstTTFonts);
    end;
    Items.EndUpdate;
  end; //with

Um das Problem einzukreisen würde ich - falls die Kunden einverstanden sind - eine minimale Anwendung die praktisch nur obigen Code enthält auf ihrem Systen testen.

[Blup]

Durch die Änderung der Items ändert sich wahrscheinlich auch der ItemIndex zu -1.
Das löst ein zugewiesenes OnChange-Ereignis aus, mit allen Folgen.

Ich würd auch testen, ob diese Variante eventuell schneller ist:

Delphi-Quellcode:

  FontBox.Items.Text := meineForm.lstTTFonts.Text;

[arnof]

schalte die combobox einfach mal auf visible:=False und versuche mal ob es dann schneller geht

[OlliWW]

Items.Text brachte nichts
Visible := False brachte auch nichts


Die Stelle wird 13 mal aufgerufen an der Stelle wo ich messe. Mit maximal 50 Items pro Aufruf. Insagesamt dauern diese 13 Durchläuft: 1,3 Sekunden. Meiner Meinung nach zu lange?

[mjustin]

Zitat:

Zitat von OlliWW (Beitrag 1274530)

Die Stelle wird 13 mal aufgerufen an der Stelle wo ich messe. Mit maximal 50 Items pro Aufruf. Insagesamt dauern diese 13 Durchläuft: 1,3 Sekunden. Meiner Meinung nach zu lange?

Das entspricht 0,1 Sekunden pro Durchlauf und ist signifikant weniger als die ursprünglichen 6 Sekunden.

Bei diesen Werten würde ich von Alarmstufe Rot auf Gelb zurückschalten, dem Hinweis auf ausgeführten Code im OnChange Ereignis würde ich aber noch nachgehen.

[OlliWW]

Das mit dem OnChange habe ich geprüft.
Es war tatsächlich so, dass ich das OnChange Ereignis erst NACH dem AddStrings zugewiesen habe und dadurch konnte ich auch einen Performancegewinn erzielen.

Dennoch bleibt die Frage:
Warum ist es nur bei RDP Verbindungen so langsam? In dem OnChange läuft übrigens ein: PopupMenü.Popup
Da dieses auch an vielen weiteren Stellen im Code aufgerufen wird, habe ich mittlerweile den Verdacht dass die Performance Probleme zwischen Delphi Code und RDP beim Popup Menü zu suchen sind.

[Dejan Vu]

Zitat:

Die Stelle wird 13 mal aufgerufen an der Stelle wo ich messe. Mit maximal 50 Items pro Aufruf. Insagesamt dauern diese 13 Durchläuft: 1,3 Sekunden.

Reicht es nicht, diese Stelle nur 1x aufzurufen, und zwar mit den *letzten* Werten? Ich meine, wen interessiert es denn, wenn sich die Vorschlagsliste einer Combobox innerhalb von 1,3 Sekunden 13 mal ändert?

[OlliWW]

Ich schrieb bereits dass die Software etwas umfangreicher ist:
wir sind hier im create einer eigenen komponente die beim create einer bestimmten form eben 13 mal läuft.

[Dejan Vu]

Ach so. 13 Comboboxen. Na gut. :oops:

[OlliWW]

Guten Abend,

Ich bin weiter gekommen:
Ich konnte die Geschwindigkeit signifikant erhöhen, indem ich in den Projekteinstellungen die Laufzeitthemes dekativiert habe. Vorher standen sie auf aktiviert und Standard Stil: Windows

Kann sich das einer erklären? :shock:

[Dejan Vu]

Na, zeichnen werden die schon die Comboboxen, und das scheint ziemlich suboptimal implementiert zu sein.

Du kannst übrigens marginal etwas verbessern: Ziehe die Abfrage, ob meineForm <> nil ist, vor das Begin/EndUpdate:

Delphi-Quellcode:

if meineForm <> nil then
  with FontBox do
    begin
    Items.BeginUpdate;
    Items.AddStrings(meineForm.lstTTFonts);
    Items.EndUpdate;
  end;

Ich bin mir auch ziemlich sicher, das dein Begin-/EndUpdate überflüssig ist und daher würde ich das Statement so einkürzen.

Delphi-Quellcode:

if meineForm<>nil then 
  FontBox.Items.AddStrings(meineForm.lstTTFonts);

Das ist lesbarer. Und schlimmer wird es auch nicht, performancetechnisch gesehen.

PS: Sicher, das keine Events an den Combos hängen?