Massive Performanceprobleme mit TJvImageComboBox

[BastiFantasti]

Hallo Forum,

Delphi 10.3.2 / JVCL Version 3.50

ich habe massive Probleme mit der Geschwindigkeit beim Befüllen des controls TJvImageCombobox.

100 Elemente sollen in die Combobox geschrieben werden.
- ohne .BeginUpdate und .EndUpdate dauert das an die 4 Sekunden
- ohne Sortierung der Einträge, mit BeginUpdate und EndUpdate um die 300ms
- mit Sortierung der Einträge, mit BeginUpdate und EndUpdate an die 900ms :roll:

Ob ein Bild pro Zeile angezeigt wird oder nicht, macht dabei Performancemäßig so gut wie keinen Unterschied.


Hat jemand eine Idee, wie das alles auf ein erträgliches Maß beschleunigt werden kann?

Beispielprojekt ist angefügt.

Danke schon mal

Gruß
Bastian

[Stevie]

Sortier die Daten bevor du sie in die Combobox schreibst.

Außerdem ist der Code in icb_add nicht optimal. Items.Add gibt dir ein TJvImageItem zurück, du kannst dir also den Count und die mehrfachen Items[cnt] Aufrufe sparen.

Das Setzen von Items.Capacity vor dem Befüllen sollte zusätzlich für eine Verbesserung sorgen.

Übrigens kannst du hier mit Assign arbeiten - TJvImageItems.Assign unterstützt TStrings als Source, inklusive dem BeginUpdate/EndUpdate - nur die Images musst du danach noch setzen.

[BastiFantasti]

Hallo und danke für die schnelle Rückmeldung.

Ich habe die UpdateBegin Funktion dahingehend umgebaut, dass das sorted schon vorher gesetzt wird.
Das hat in der Tat den Geschwindigkeitsunterschied von der sortierten zur unsortierten Liste verschwinden lassen.
Den Count hab ich raus gemacht und arbeite nun direkt mit dem zurückgegebenen Objekt.
Das hat so weit auch funktioniert.

Das hinzufügen von items.capacity hat keine Änderung bewirkt.

Sortierte, sowie unsortierte Liste benötigten nun 350ms für 100 Einträge

350ms für 100 Elemente ist aber immer noch zu lang.
Ich werde das mit dem Assign noch versuchen

[BastiFantasti]

Hallo,

hier noch ein kleines Update

bzgl. des Sortierens meinst du, dass das in der Stringlist und nicht in der Combobox passieren soll, oder?

Bei der Combobox muss man zwingend das sorted am Anfang auf False setzen.
Wenn man das zu Beginn gleich auf True setzt geht es davon aus, dass die Daten schon sortiert sind...

[BastiFantasti]

So,

hab das "sorted" komplett raus geworfen und die Daten im Vorfeld sortiert.
Jetzt klappt es, dass die Daten sortiert sind und auch in 350ms in die Combobox geschrieben werden.

Im zweiten Versuch hab ich jetzt noch mit Assign die Elemente aus der Stringliste direkt hinzugefügt.
Das bringt interessanter Weise leider keine Änderung beim Timing...

Mir ist noch aufgefallen, dass das Leeren der Combobox auch eine geraume Zeit in Anspruch nimmt.
Der erste Durchlauf dauert immer an die 190ms und alle darauffolgenden 300-400ms (wenn also Daten vorhanden sind die entfernt werden müssen)

Hab den neuen Stand mal angehängt...
Was kann man noch machen um das Verwalten der Daten in der Combobox zu beschleunigen?

Danke und Gruß
Bastian

[Aviator]

Ich kann leider nichts zu den Jedi Komponenten beitragen. Mit denen habe ich mich schonmal rumgeärgert, sie dann deinstalliert und nie wieder verwendet.

Wenn du aber so viele Probleme beim Anzeigen von ein paar wenigen Items hast, dann empfehle ich dir, dich mal mit dem VirtualTreeView auseinanderzusetzen. In meinen Augen eine der besten Komponenten der Welt. Zuverlässig, extrem flexibel, Open Source, ...

Also schau sie dir mal an. Einziger Nachteil wenn du noch nie damit gearbeitet hast ... die Lernkurve ist etwas steiler als bei manch anderen Komponenten.

[Pawel Piotrowski]

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.

[BastiFantasti]

Hallo und danke für die Tipps.

Dann werde ich mir mal den VirtualTreeView anschauen.

Ich werde berichten ...

Danke nochmals

Gruß
Bastian

[Stevie]

Sorry, aber wenn es bei dir 350ms Dauert, 100 Items hinzuzufügen ist entweder irgendwas mit deinen Compileroptionen nicht in Ordnung oder du arbeitest auf ner Uralt CPU - mit meinem schon betagten i5 geht das in 40ms

Delphi-Quellcode:

    icb1.Items.Clear;
    if cbSorted.Checked then
      myds.Sort;
    icb1.Items.BeginUpdate;
    try
      for iter := 0 to myds.Count - 1 do
      begin
        item := icb1.Items.Add;
        item.Text := myds[iter];
        if cbWithPic.Checked then
          item.ImageIndex := iter mod 2;
      end;
    finally
      icb1.Items.EndUpdate;
    end;

[Pawel Piotrowski]

Das ist sehr interessant. Ich wundere mich, wo der Unterschied liegt?
Bei mir ist es sogar noch langsamer als bei BastiFantasti .

ich habe einen i7 6700K @4GHz

Habe mal ein neues blanko Projekt erstellt, etwas vereinfacht.
Nur ein TButton, TMemo und natuerlich JvImageComboBox plaziert.
delphi Rio
Release build
JEDI VCL Library Version 3.50

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
  st, stClear, stAdd, stSetText: TStopWatch;
  x: Integer;
  j: Integer;
  item: TJvImageItem;
begin
  for x := 0 to 9 do
  begin
      st := TStopWatch.startNew;
    stAdd.Reset;
    stSetText.Reset;
    stClear.Reset;

    JvImageComboBox1.items.BeginUpdate;
    try
      stClear.start;
      JvImageComboBox1.items.clear;
      stClear.Stop;

      for j := 0 to 99 do
      begin
          stAdd.start;
        item := JvImageComboBox1.items.Add;
        stAdd.Stop;

        stSetText.start;
        item.Text := 'abcdefgh' + IntToStr(j);
        stSetText.Stop;
      end;

    finally
      JvImageComboBox1.items.EndUpdate;
    end;

    st.Stop;
    Memo1.Lines.Add(
      format(
      '#%d. done in %d ms; clear: %d ms; add: %d ms; setText: %d ms',
      [(x + 1),
      st.ElapsedMilliseconds,
      stClear.ElapsedMilliseconds,
      stAdd.ElapsedMilliseconds,
      stSetText.ElapsedMilliseconds]));
  end;
  
end;

Und so sehen meine Resultate aus:

Delphi-Quellcode:

#1. done in 367 ms; clear: 0 ms; add: 34 ms; setText: 274 ms
#2. done in 728 ms; clear: 420 ms; add: 28 ms; setText: 231 ms
#3. done in 697 ms; clear: 381 ms; add: 32 ms; setText: 234 ms
#4. done in 679 ms; clear: 367 ms; add: 29 ms; setText: 234 ms
#5. done in 719 ms; clear: 376 ms; add: 35 ms; setText: 259 ms
#6. done in 753 ms; clear: 390 ms; add: 39 ms; setText: 271 ms
#7. done in 779 ms; clear: 427 ms; add: 30 ms; setText: 255 ms
#8. done in 791 ms; clear: 375 ms; add: 36 ms; setText: 322 ms
#9. done in 728 ms; clear: 397 ms; add: 29 ms; setText: 227 ms
#10. done in 744 ms; clear: 391 ms; add: 33 ms; setText: 271 ms

[BastiFantasti]

Ich kann die Ergebnisse von Pawel so auch bestätigen.
An meinem Rechner sollte es nicht liegen. Ist ein i7-6700

Der erste Durchlauf mit leerem Control liegt bei < 200ms und alle darauffolgenden fast 200ms drüber
Das Leeren bzw. Freigeben der Elemente dauert exorbitant lang.
Bei der Tabelle von Pawel sieht man sehr gut, dass das leeren stellenweise länger dauert als das neu befüllen...


@Stevie mit welcher Delphi Version hast du das getestet?

[Schokohase]

Das Entfernen und erneute Erzeugen von Instanzen ist immer schlecht für die Performance.

Warum verwendest du die bereits vorhandenen Einträge nicht wieder? Dann geht das auch wesentlich schneller.

Delphi-Quellcode:

procedure UpdateItems(const AItems: TJvImageItems; const AValues: TStrings);
var
  itemIndex: Integer;
  itemTemplate: TJvImageItem;
begin
  AItems.BeginUpdate();
  try
    // zuviele Einträge -> löschen vom Ende
    while AItems.Count > AValues.Count do
      AItems.Delete(AItems.Count-1);
    // zuwenig Einträge -> neue anfügen
    while AItems.Count < AValues.Count do
      AItems.Add;

    // Template erstellen
    itemTemplate := TJvImageItem.Create(AItems);
    try
      for itemIndex := 0 to AValues.Count -1 do
      begin
        // Template Werte setzen
        itemTemplate.Text := AValues[itemIndex];
        
        // Template zuweisen
        AItems[itemIndex].Assign(itemTemplate);
      end;
    finally
      FreeAndNil(itemTemplate);
    end;
  finally
    AItems.EndUpdate();
  end;  
end;

[Stevie]

Zitat:

Zitat von BastiFantasti (Beitrag 1445304)

@Stevie mit welcher Delphi Version hast du das getestet?

Mit 10.1.2 - das ist unsere produktive Version.

Code aus Beitrag #10 mit 10.3.2 (sowohl jcl als auch jvcl neuster stand von github):

Code:

#1. done in 18 ms; clear: 0 ms; add: 3 ms; setText: 10 ms
#2. done in 31 ms; clear: 14 ms; add: 2 ms; setText: 9 ms
#3. done in 31 ms; clear: 13 ms; add: 2 ms; setText: 10 ms
#4. done in 30 ms; clear: 13 ms; add: 2 ms; setText: 9 ms
#5. done in 30 ms; clear: 13 ms; add: 2 ms; setText: 9 ms
#6. done in 30 ms; clear: 13 ms; add: 2 ms; setText: 9 ms
#7. done in 29 ms; clear: 13 ms; add: 2 ms; setText: 9 ms
#8. done in 30 ms; clear: 13 ms; add: 2 ms; setText: 9 ms
#9. done in 30 ms; clear: 13 ms; add: 2 ms; setText: 9 ms
#10. done in 29 ms; clear: 13 ms; add: 2 ms; setText: 9 ms

[BastiFantasti]

Hier die Ergebnisse von mir, Delphi 10.3.2 / x86 / jcl und jvcl werde ich mal von github aktualisieren...

Code:

#1. done in 411 ms; clear: 178 ms; add: 24 ms; setText: 174 ms
#2. done in 314 ms; clear: 161 ms; add: 16 ms; setText: 107 ms
#3. done in 406 ms; clear: 194 ms; add: 24 ms; setText: 162 ms
#4. done in 302 ms; clear: 157 ms; add: 15 ms; setText: 101 ms
#5. done in 411 ms; clear: 260 ms; add: 17 ms; setText: 109 ms
#6. done in 317 ms; clear: 163 ms; add: 19 ms; setText: 98 ms
#7. done in 386 ms; clear: 241 ms; add: 15 ms; setText: 98 ms
#8. done in 386 ms; clear: 163 ms; add: 19 ms; setText: 160 ms
#9. done in 315 ms; clear: 177 ms; add: 16 ms; setText: 98 ms
#10. done in 390 ms; clear: 163 ms; add: 21 ms; setText: 180 ms

[BastiFantasti]

@Stevie kannst du deine Compilereinstellungen mal posten?

[Stevie]

Delphi-Quellcode:

{$A8,B-,C+,D+,E-,F-,G+,H+,I+,J-,K-,L+,M-,N-,O+,P+,Q-,R-,S-,T-,U-,V+,W-,X+,Y+,Z1}

Aber ich glaub ja eher, das liegt an irgendwelchen jcl/jvcl Einstellungen bei deren Installation, dass da evtl noch irgendwelche string Konvertierungen oder sonstwas laufen.

[BastiFantasti]

ja das kann sein.

Ich hab gerade den letzten Stand von github geholt (JCL und JVCL)
die libs aktualisiert und bekomme immer noch gleiche Ergebnisse

ohne deine Compilerschalter zu testen.

Code:

#1. done in 134 ms; clear: 0 ms; add: 15 ms; setText: 95 ms
#2. done in 291 ms; clear: 155 ms; add: 16 ms; setText: 94 ms
#3. done in 378 ms; clear: 242 ms; add: 15 ms; setText: 95 ms
#4. done in 340 ms; clear: 162 ms; add: 17 ms; setText: 123 ms
#5. done in 345 ms; clear: 203 ms; add: 15 ms; setText: 99 ms
#6. done in 376 ms; clear: 157 ms; add: 19 ms; setText: 171 ms
#7. done in 283 ms; clear: 151 ms; add: 14 ms; setText: 92 ms
#8. done in 379 ms; clear: 185 ms; add: 20 ms; setText: 146 ms
#9. done in 295 ms; clear: 154 ms; add: 16 ms; setText: 101 ms
#10. done in 386 ms; clear: 247 ms; add: 16 ms; setText: 98 ms

Der Test folgt gleich noch

[BastiFantasti]

so, den Test mit deinen Compilereinstellungen hab ich gemacht - leider ohne Änderung des Problems.
Somit wird es wohl an der Installationsart der JVCL Komponenten liegen.

Hast du da irgendwas spezielles ausgewählt oder abgewählt?
Ich hab es bei mir mit den Standardeinstellungen durchinstalliert.

[Stevie]

Im Anhang mal die Einträge aus den ini Dateien, die neben den Installern erzeugt werden mit den Einstellungen und das Testprojekt, damit wir auch sicherstellen können, dass es nicht an etwas anderen liegt, wenn du damit auch schnelle Zeiten hinbekommst

P.S. Falls die eine oder andere Einstellung seltsam anmutet, das ist das, was ich zuletzt ausprobiert habe ums auch langsam zu bekommen, ohne Erfolg.

[BastiFantasti]

Vielen Dank schon mal

ich hab deine EXE getestet, hier die Ergebnisse:

Code:

#1. done in 135 ms; clear: 0 ms; add: 14 ms; setText: 99 ms
#2. done in 333 ms; clear: 182 ms; add: 18 ms; setText: 109 ms
#3. done in 285 ms; clear: 154 ms; add: 14 ms; setText: 94 ms
#4. done in 324 ms; clear: 196 ms; add: 13 ms; setText: 91 ms
#5. done in 278 ms; clear: 147 ms; add: 14 ms; setText: 92 ms
#6. done in 332 ms; clear: 205 ms; add: 13 ms; setText: 90 ms
#7. done in 314 ms; clear: 166 ms; add: 15 ms; setText: 98 ms
#8. done in 303 ms; clear: 175 ms; add: 14 ms; setText: 90 ms
#9. done in 308 ms; clear: 143 ms; add: 17 ms; setText: 113 ms
#10. done in 303 ms; clear: 170 ms; add: 15 ms; setText: 93 ms

langsam fall ich vom Glauben ab...

Welches Windows verwendest du?

Ich Win 10 Pro x64 (Version 10.0.18362 Build 18362)
Prozessor Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3408 MHz, 4 Kern(e), 8 logische(r) Prozessor(en)
Installierter physischer Speicher (RAM) 16,0 GB


Update:
Deine Exe läuft bei meinem Kollegen wunderbar mit 8-16ms ...

Es muss also ein Windows Problem sein

[Stevie]

Windows 8.1 bei mir aber läuft genauso schnell auf nem Windows 10 vom Kollegen.

Ich würd mal auf nen "schlechten" Windows Patch tippen :)

[franktron]

Ich habe das auch mal getestet
VMWare Workstation VM 16 GB RAM AMD Phenom

#1. done in 42 ms; clear: 0 ms; add: 9 ms; setText: 20 ms
#2. done in 74 ms; clear: 21 ms; add: 7 ms; setText: 18 ms
#3. done in 73 ms; clear: 19 ms; add: 13 ms; setText: 27 ms
#4. done in 68 ms; clear: 20 ms; add: 11 ms; setText: 24 ms
#5. done in 64 ms; clear: 21 ms; add: 9 ms; setText: 21 ms
#6. done in 65 ms; clear: 25 ms; add: 7 ms; setText: 18 ms
#7. done in 64 ms; clear: 21 ms; add: 9 ms; setText: 21 ms
#8. done in 68 ms; clear: 24 ms; add: 7 ms; setText: 18 ms
#9. done in 79 ms; clear: 24 ms; add: 9 ms; setText: 21 ms
#10. done in 63 ms; clear: 20 ms; add: 9 ms; setText: 21 ms

Das hat also nix mit der Rechenleistung zu tun.
Ich würde aber die Grafikkarte in bezug nehem nda die Werte auf dem Host Windows 7 nur halb so lange brauchen.

[BastiFantasti]

meinst du das die GraKa da irgendie die Finger mit drin haben kann?

Der wine Kollege hat ne onboard Intel in Lenovo Notebook, Win 10 Home -> schnell

Anderer Kollege hat ein Dell XPS13 auch onboard Intel, Win 10 Pro -> langsam

bei mir Win 10 pro, Dell Desktop Rechner, Nvidia Quadro K(irgendwas) -> langsam

[stahli]

Mal ins Blaue: Kann es vielleicht etwas mit timeBeginPeriod zu tun haben? https://www.delphipraxis.net/1350657-post15.html

Ich sehe zwar kein Sleep im Code, aber wer weiß, was da noch im Hintergrund läuft...

[BastiFantasti]

es wird immer komischer...

auf meinem Host ist es langsam

Code:

#1. done in 140 ms; clear: 0 ms; add: 16 ms; setText: 100 ms
#2. done in 366 ms; clear: 175 ms; add: 22 ms; setText: 143 ms
#3. done in 293 ms; clear: 159 ms; add: 14 ms; setText: 96 ms
#4. done in 383 ms; clear: 220 ms; add: 18 ms; setText: 119 ms
#5. done in 295 ms; clear: 161 ms; add: 15 ms; setText: 95 ms
#6. done in 370 ms; clear: 232 ms; add: 15 ms; setText: 96 ms
#7. done in 323 ms; clear: 162 ms; add: 16 ms; setText: 109 ms
#8. done in 337 ms; clear: 202 ms; add: 15 ms; setText: 98 ms
#9. done in 369 ms; clear: 162 ms; add: 19 ms; setText: 155 ms
#10. done in 297 ms; clear: 156 ms; add: 16 ms; setText: 100 ms

in Virtualbox VM (win7) auf meinem Rechner schnell

Code:

Memo1
#1. done in 25 ms; clear: 0 ms; add: 3 ms; setText: 14 ms
#2. done in 47 ms; clear: 19 ms; add: 4 ms; setText: 17 ms
#3. done in 46 ms; clear: 20 ms; add: 5 ms; setText: 14 ms
#4. done in 46 ms; clear: 19 ms; add: 3 ms; setText: 15 ms
#5. done in 50 ms; clear: 19 ms; add: 6 ms; setText: 16 ms
#6. done in 47 ms; clear: 21 ms; add: 4 ms; setText: 16 ms
#7. done in 45 ms; clear: 19 ms; add: 5 ms; setText: 13 ms
#8. done in 46 ms; clear: 18 ms; add: 4 ms; setText: 15 ms
#9. done in 46 ms; clear: 19 ms; add: 5 ms; setText: 14 ms
#10. done in 48 ms; clear: 20 ms; add: 4 ms; setText: 17 ms

[franktron]

Virenscanner ? vielleicht

[BastiFantasti]

Zitat:

Zitat von franktron (Beitrag 1445528)

Virenscanner ? vielleicht

Auf meinem Win10 Rechner verwend ich den Microsoft Virenscanner
auf dem XPS13 Win10 ist F-Secure installiert

auf beiden ist die Funktion langsam

Beim anderen Kollegen mit Win10 Home ist auch F-Secure installiert, da läuft es schnell...

[Pawel Piotrowski]

Bei mir sieht es auch genauso aus wie bei BastiFantasti .

Langsam kommen wir aber der Sache näher ;)

ich hab die EXE von Stevie getestet.
Läuft genauso langsam wie die, die ich selbst kompiliere.
Es liegt also zum Glück nicht an Delphi oder gar der JVCL. Nicht direkt jedenfalls.

Mein system:
Windows 10 home x64 (Version 1903 Build 18362.329)
Prozessor Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4 Kern(e), 8 logische(r) Prozessor(en)
RAM: 32 GB
GrafikKarte: NVIDIA GeForce GTX 1050, 2GB RAM

Interessanterweise läuft die exe bei mir ~2x langsamer als bei BastiFantasti, obwohl ich einen etwas schnelleren Processor zu haben scheine.

Virenscanner auschalten bringt bei mir keine verbesserung.

Werde spaeter noch andere windows Version in VM gegentesten.

[Stevie]

Lasst die Anwendung mal unter SamplingProfiler laufen, evtl zeigt sich dort eine Auffälligkeit.

Projekt mit TD32 (der Haken Debugsymbole in auf der Linker page) oder Mapfile kompilieren.
Sollten dann ein paar mehr Durchläufe/Items sein, damit genug Samples genommen werden.

[BastiFantasti]

hab das mal gemacht
hab dazu die Anwendung etwas umgebaut

- die Anwendung startet den Testlauf nun automatisch
- ich mach nun 31 iterationen a 500 Einträge um mehr Samples zu generieren
- Danach beendet sich die Anwendung wieder

Die Ergebnisse sind im Anhang (leider als zip weil spr nicht erlaubt)

[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.