Kann ich meine ListView beschleunigen (Icon laden dauert ewig)

[Schokohase]

Zitat von EWeiss:

TThread.Synchronize (TThread.CurrentThread, Bist sicher? Nicht Nil!

Du kannst da übergeben was du möchtest - der Wert wird im Prinzip nicht wirklich verwendet.

Die Thread-Instanz wird in einen Record geschrieben:

Delphi-Quellcode:

class procedure TThread.Synchronize(const AThread: TThread; AMethod: TThreadMethod);
var
  FSynchronize: TSynchronizeRecord;
begin
  FSynchronize.FThread := AThread; // da
  FSynchronize.FSynchronizeException := nil;
  FSynchronize.FMethod := AMethod;
  FSynchronize.FProcedure := nil;
  Synchronize(@FSynchronize);
end;

class procedure TThread.Synchronize(const AThread: TThread; AThreadProc: TThreadProcedure);
var
  FSynchronize: TSynchronizeRecord;
begin
  FSynchronize.FThread := AThread; // oder da
  FSynchronize.FSynchronizeException := nil;
  FSynchronize.FMethod := nil;
  FSynchronize.FProcedure := AThreadProc;
  TThread.Synchronize(@FSynchronize);
end;

und dann wird ein TNotifyEvent damit aufgerufen:

Delphi-Quellcode:

class procedure TThread.Synchronize(ASyncRec: PSynchronizeRecord; QueueEvent: Boolean = False; ForceQueue: Boolean = False);
var
  SyncProc: TSyncProc;
  SyncProcPtr: PSyncProc;
begin
  [...]
        if Assigned(WakeMainThread) then
          WakeMainThread(SyncProcPtr.SyncRec.FThread);
  [...]
end;

der bei einer VCL-Anwendung mit dieser Methode verbunden ist:

Delphi-Quellcode:

procedure TApplication.WakeMainThread(Sender: TObject);
begin
  PostMessage(Handle, WM_NULL, 0, 0);
end;

Wie man sieht, mit der schönen Instanz die mit Sender übergeben wird, wird schon mal gar nichts gemacht.
(BTW: Bei FMX sieht es auch nicht besser aus)

Fazit
Es ist völlig egal ob man dort eine Instanz des aktuellen Threads, oder irgendeine Instanz oder eine ungültige oder eben einfach gar keine mit nil übergibt. Somit besteht kein Grund zur Sorge, wenn jemand dort eine Instanz übergibt.

Darum sollte man hier auch ganz beherzt ein nil übergeben, denn das ist kürzer und gaukelt auch keine sonstige Funktionalität vor.

[Hobbycoder]

Zitat von Delphi.Narium:

Zitat von Hobbycoder:

Hm...würde mir einer mal erklären, warum BeginUpdate und EndUpdate einer ListView nicht ausreichen, und zusätzlich noch das Minimize btw. Restore mehr Geschwindigkeit bringen soll?

Weil dann jegliche Aktuallisierung des Bildschirmes / der Anzeige wegfällt. Und das dauert unter Windows halt.

Ist 'ne langjährige praktische Erfahrung / Beobachtung, die man halt ausnützen kann, wenn was schneller gehen soll.

Ja, ist klar. Aber ist das nicht schon durch das ListView.BeginUpdate sichergestellt, dass aus diesem heraus keinerlei Zeichenvorgänge ausgelöst werden, solange ListView.EndUpdate nicht ausgeführt wird?

(Mal davon ausgehend, dass durch die Sammelroutine nicht noch andere Controls verändert werden).

[Delphi.Narium]

Zitat von Hobbycoder:

(Mal davon ausgehend, dass durch die Sammelroutine nicht noch andere Controls verändert werden).

Aber genau dort scheint der Haken zu liegen.

Hab' letzlich ein Programm geschrieben, dass Textdateien einliest, daraus eine Wortliste erstellt, um diesen dann als 1:n-Beziehung in 'ne Datenbank zu schreiben (dient der schnellen Suche nach Inhalten, quasi sowas wie Google light für lokale Dateien). Die Datenbankinteraktion erfolgt ausschließlich über Select- und Insert-Statements per ExecSQL, also keine datensensitiven Controls.

Damit man was sieht, gibt es 'ne Progressbar, die halt alle 100 oder so ähnlich Statements eine Position weitergeht.

Sonst wird nix an der Oberfläche geändert.

Das Programm wird minimiert mindestens um den Faktor 10 schneller, auch dann, wenn ich auf die Progressbar verzichte.

Statusänderungen, Fortschrittsanzeige mache ich nun, in dem ich alle 100 Sätze den Application.Title, bei minimiertem Programm, ändere. Dann sieht man immernoch den Fortschritt, aber die Oberfläche bleibt unsichtbar. Damit ist es (warum auch immer) deutlich schneller.
Bei der großen Datenmenge, die zu verarbeiten ist, summiert sich das auf Laufzeitverkürzungen von vielen Stunden bis zu mehreren Tagen.

Vermutlich sollte man sowas dann direkt als Konsolenprogramm schreiben.

[Uwe Raabe]

Zitat von Hobbycoder:

Aber ist das nicht schon durch das ListView.BeginUpdate sichergestellt, dass aus diesem heraus keinerlei Zeichenvorgänge ausgelöst werden, solange ListView.EndUpdate nicht ausgeführt wird?

Die ImageList-Changes z.B. gehen aber an dem BeginUpdate/EndUpdate vorbei und landen direkt im Control.

[Uwe Raabe]

Zitat von Schokohase:

Du kannst da übergeben was du möchtest - der Wert wird im Prinzip nicht wirklich verwendet.

Für Synchronize stimmt das, aber bei Queue spielt es schon eine Rolle.

[Hobbycoder]

Zitat von Delphi.Narium:

Zitat von Hobbycoder:

(Mal davon ausgehend, dass durch die Sammelroutine nicht noch andere Controls verändert werden).

Aber genau dort scheint der Haken zu liegen.

Damit man was sieht, gibt es 'ne Progressbar, die halt alle 100 oder so ähnlich Statements eine Position weitergeht.

Sonst wird nix an der Oberfläche geändert.

Gut. In dem Fall ist aber eben auch ein Control beteiligt, welches neu gezeichnet werden muss. Da ist das ja klar, dass das Zeit kostet. Und dann auch warum eine Minimize auch was bringt. Aber wenn eben kein weiteres Control beteiligt ist, sollte BeginUpdate reichen.

Zitat von Uwe Raabe:

Zitat von Hobbycoder:

Aber ist das nicht schon durch das ListView.BeginUpdate sichergestellt, dass aus diesem heraus keinerlei Zeichenvorgänge ausgelöst werden, solange ListView.EndUpdate nicht ausgeführt wird?

Die ImageList-Changes z.B. gehen aber an dem BeginUpdate/EndUpdate vorbei und landen direkt im Control.

Das ist natürlich schlecht. Würde es da nicht reichen, vor dem Begin im ListView die ImageList-Verbindung auf nil zu setzen und nach dem die ImageList alle benötigten Images enthält und alle ListItems erzeugt sind vor dem EndUpdate diese Verbinung wiederherzustellen?

[EWeiss]

Zitat:

Darum sollte man hier auch ganz beherzt ein nil übergeben, denn das ist kürzer und gaukelt auch keine sonstige Funktionalität vor.

Da bin ich ja auf der richtigen Seite.. Ok bin raus.

gruss

[Schokohase]

Zitat von Uwe Raabe:

Zitat von Schokohase:

Du kannst da übergeben was du möchtest - der Wert wird im Prinzip nicht wirklich verwendet.

Für Synchronize stimmt das, aber bei Queue spielt es schon eine Rolle.

Könntest du erklären wie oder welche Rolle? Ich sehe aktuell nicht, wo diese Information (Instanz von TThread ) auch beim TThread.Queue sinnvoll verwendet wird.

Auch TThread.Queue ruft intern class procedure TThread.Synchronize(ASyncRec: PSynchronizeRecord; QueueEvent: Boolean = False; ForceQueue: Boolean = False) auf und das habe ich oben erläutert.

Aber bestimmt übersehe ich da etwas ...

[KodeZwerg]

Zitat von Hobbycoder:

Das ist natürlich schlecht. Würde es da nicht reichen, vor dem Begin im ListView die ImageList-Verbindung auf nil zu setzen und nach dem die ImageList alle benötigten Images enthält und alle ListItems erzeugt sind vor dem EndUpdate diese Verbinung wiederherzustellen?

Guter Einfall, habs gerade getestet, vom Faktor Zeit ausgehend ist es gleich. Danke trotzdem!
Ich bin jetzt auf Hide und Show umgestiegen, das erspart dem Rechner eine Animation abzuspielen

[Uwe Raabe]

Zitat von Schokohase:

Könntest du erklären wie oder welche Rolle? Ich sehe aktuell nicht, wo diese Information (Instanz von TThread ) auch beim TThread.Queue sinnvoll verwendet wird.

Auch TThread.Queue ruft intern class procedure TThread.Synchronize(ASyncRec: PSynchronizeRecord; QueueEvent: Boolean = False; ForceQueue: Boolean = False) auf und das habe ich oben erläutert.

TThread.Destroy ruft TThread.RemoveQueuedEvents auf und dort werden alle noch nicht erledigten Queue-Events für diesen Thread gelöscht und somit nicht mehr ausgeführt. Übergibt man beim Queue ein nil, kommen die Events auch noch an wenn der auslösende Thread schon weg ist.