Massive Performanceprobleme mit TJvImageComboBox

[BastiFantasti]

und hier noch das gleiche Programm auf dem Rechner vom Kollegen wo alles iO ist

[BastiFantasti]

und hier noch eins von nem Win7 Rechner mit gleichem Problem

[Stevie]

Was mir auffällt ist, dass bei den langsamen Systemen TJvComboBoxStrings.GetObject relativ viel Zeit verbraucht.
Sind auf den betroffenen Systemen evtl irgendwelche Messagehooks jeglicher Form im Gange?

Dazu gehören zum Beispiel so Windows Inspector Tools wie Microsoft Spy++, Winspector Spy etc

P.S. Jupp, wenn ich Spy++ aufmache wird's bei mir auch langsam.

[BastiFantasti]

wie kann man rausfinden ob da irgendwelche Programme aktiv sind die die Messages überwachen?

Von den genannten Programmen läuft bei mir wissentlich zumindest keins.
Werde aber in die Richtung mal schauen ob ich was rausfinden kann...

[Pawel Piotrowski]

Bei mir läuft NVDA, das ist ein Screenreader da ich ein klein wenig blind bin.
Wenn ich es ausschalte läuft die Anwendung schnell.
Wenn ich es wieder einschalte, läuft die wieder langsam.
Im meinem Fall hat es sich also geklärt.

[TurboMagic]

Zitat:

Zitat von Pawel Piotrowski (Beitrag 1444946)

Dem kann ich mich nur anschließen. Vergiss die TJvImageCombobox.
Das Hinzufügen der Items ist langsam, weil, unter anderen, dabei die TJvImageCombobox mehrere IndexOf aufrufe macht...

kommentiere mal das setzen des Textes aus - füge also leere Items hinzu. Du wirst sehen, der Code wird ca. 2x schneller

wenn Du dir die procedure TJvImageItem.SetText anschaust
findest Du z.B. so was am ende:

Index := S.IndexOfObject(Self);

So etwas wird in dieser Klasse leider in mehreren Stellen vorgenommen.
Und das ist nicht das einzige Bottleneck...
Die TJvImageCombobox eignet sich nur, wenn Du weniger als ~20 items hast.

Ok, es muss am Ende der Index ermittelt werden, was wohl verhältnismäßig viel Zeit
schluckt. Gäbe es eine andere Möglichkeit den zu ermitteln?

Zum Beispiel, in dem man diesen im Ablauf weiter oben je nach Fall entsprechend zuweist?

Zum Beispiel so?

Delphi-Quellcode:

procedure TJvImageItem.SetText(const Value: string);
var
  S: TStrings;
  SavedOwner: TJvImageItems;
begin
  S := GetOwnerStrings;
  if Assigned(FOwner) and (FOwner.FStrings.Count <> FOwner.Count) then
    FOwner.FillItems;
  if S <> nil then
  begin
    if S[Index] <> Value then
    begin
      // do not add the item in FillItems which might be called by the draw message handler while deleting the string
      SavedOwner := FOwner;
      try
        FOwner := nil;
        S.Delete(Index);
        if (SavedOwner.GetOwner is TJvImageListBox) and (TJvImageListBox(SavedOwner.GetOwner).Sorted) then
          Index := S.AddObject(Value, Self)
        else
          S.InsertObject(Index, Value, Self);
      finally
        FOwner := SavedOwner;
      end;
//      Index := S.IndexOfObject(Self);
      Change;
    end;
  end;
end;

[Pawel Piotrowski]

Nein. Damit schaltest Du das sortieren ganz ab.

Mache es so:

Delphi-Quellcode:

 procedure TJvImageItem.SetText(const Value: string);
var
  S: TStrings;
  SavedOwner: TJvImageItems;
begin
  S := GetOwnerStrings;
  if Assigned(FOwner) and (FOwner.FStrings.Count <> FOwner.Count) then
    FOwner.FillItems;
  if S <> nil then
  begin
    if S[Index] <> Value then
    begin
      // do not add the item in FillItems which might be called by the draw message handler while deleting the string
      SavedOwner := FOwner;
      try
        FOwner := nil;
        // S.Delete(Index); - nicht hier
        if (SavedOwner.GetOwner is TJvImageListBox) and (TJvImageListBox(SavedOwner.GetOwner).Sorted) then
      begin
      S.Delete(Index); // hier besser
          Index := S.AddObject(Value, Self);
        end else
          S[Index]:= value; // reicht doch
      finally
        FOwner := SavedOwner;
      end;
// Index := S.IndexOfObject(Self);
      Change;
    end;
  end;
end;

[TurboMagic]

Zitat:

Zitat von Pawel Piotrowski (Beitrag 1446277)

Nein. Damit schaltest Du das sortieren ganz ab.

Mache es so:

Delphi-Quellcode:

 procedure TJvImageItem.SetText(const Value: string);
var
  S: TStrings;
  SavedOwner: TJvImageItems;
begin
  S := GetOwnerStrings;
  if Assigned(FOwner) and (FOwner.FStrings.Count <> FOwner.Count) then
    FOwner.FillItems;
  if S <> nil then
  begin
    if S[Index] <> Value then
    begin
      // do not add the item in FillItems which might be called by the draw message handler while deleting the string
      SavedOwner := FOwner;
      try
        FOwner := nil;
        // S.Delete(Index); - nicht hier
        if (SavedOwner.GetOwner is TJvImageListBox) and (TJvImageListBox(SavedOwner.GetOwner).Sorted) then
      begin
      S.Delete(Index); // hier besser
          Index := S.AddObject(Value, Self);
        end else
          S[Index]:= value; // reicht doch
      finally
        FOwner := SavedOwner;
      end;
// Index := S.IndexOfObject(Self);
      Change;
    end;
  end;
end;

Danke für die Antwort und den Code.
Ist der schon getestet?
Hast du evtl. auch mal eine kleine vergleichende Laufzeitmessung mit dem
alten Code vorgenommen?

Wenn der Code so richtig funktioniert könnte ich einen Pull Request erstellen,
damit alle JVCL Nutzer davon profitieren.

[TurboMagic]

Zitat:

Zitat von Pawel Piotrowski (Beitrag 1446277)

Mache es so:

Snip!

Ja, ich hab's so gemacht und ein kleines Testprojekt das jedesmal die Liste löscht und
in BeginUpdate / Endupdate 130 Items hinzufügt brauchgt laut TStopWatch Messung ein paar ms weniger.

Daher habe ich einen Pull Request daraus gemacht in der Hoffnung, das in die JVCL reich zu bekommen:
https://github.com/project-jedi/jvcl/pull/139

Ich hoffe das ist ok so (auskommentierten Code und ein paar Kommentare habe ich entfernt.

[BastiFantasti]

Das Sortieren scheint generell ein Problem zu sein.
Wenn wie von Steve vorgeschlagen vorher sortiert wird, kann man sich diese zusätzlichen ms sparen.
Prinzipiell sollte es aber dennoch ohne so viel Zeitverlust funktionieren.

Ich werde die Änderungen aus deinem Pull Request bei mir noch testen.
Den Problemprozess der da lauscht konnte ich immer noch nicht herausfinden.
Ich habe es mit memory dumps und einer anschließenden Untersuchung mittels forensischer Software (volatility 2.6) versuchen wollen (ja, ist etwas mit Kanonen auf Spatzen geschossen - aber was tut man nicht alles :? )

Leider hat die Software sämtliche dumps verschmäht.
Es gibt innerhalb von volatility direkt eine Funktion nach Prozessen zu suchen die sich in das Messaging einklinken.
Wenn das jemand bei sich ans laufen bekommt könnte das ggf. auch einen Hinweis liefern.