Zitat:

Es auf 1 Sekunde zu verlängern bringt auch nix, dann braucht er 10 mal so lang zum verarbeiten der Daten.

Da has du doch schon das eigentliche Problem?

Die Arbeit im Hauptthread muß weniger sein, als wie die Zeit bis zu den nächsten Daten.


entweder die Arbeit beschleunigen,
oder weniger Daten senden

oder z.B. statt Array eine threadsave Queue/Liste, wo sich der Hauptthread so schnell/langsam Daten raus holt, wie er kann
und das Mehr an Daten drin bleibt, bis er Zeit hat.
Das geht natürlich nur um "Spitzen" abzufangen oder später nachzuarbeiten, aber insgesamt weniger Daten eintreffen, als über die ganze Zeit maximal verarbeitet werden kann.
bzw. wenn es irgendwann reicht, nachdem der Thread mal fertig ist und danach der Hauptthread das dann in Ruhe fertig machen kann.





Ich hab mich grade realtime in Windows-Event-Tracing reingehängt
und für die ersten Versuche einfach nur aus dem Thread in ein Memo geschrieben ... nach ner gewissen kurzen Zeit passiert es dann immer wieder, das Alles hängt und mir Events verloren gehen, weil der Lese-Thread ebenfalls zum Stocken kommt.

Ich könnte zwar auch auf LogFile(s) umstellen, aber das verursacht wieder andere Probleme (z.B. das FestplattenLog loggt sich selber)
Nja, im Grunde hab ich mir jetzt eine Queue-ListeArray gebastelt, weil bei der Menge an Durchsatz die bestehenden Listen wieder ihre Problme haben. (Speichermanagement und zu häufiges Umkopieren)

Zitat von himitsu:

Zitat:

Es auf 1 Sekunde zu verlängern bringt auch nix, dann braucht er 10 mal so lang zum verarbeiten der Daten.

Da has du doch schon das eigentliche Problem?

Ja und nein.
Die lokale DB schafft einfach mehr Daten herbei, als der MainThread verarbeiten kann.
Deswegen habe ich das Intervall auf 100ms gesetzt.

Mit einer RemoteDB kommen pro 100ms ca. so viele Daten an, dass der MainThread diese in weniger als 5ms verarbeiten kann.
In der Regel kommen hier maximal 500k.

Bei der lokalen dauert es manchmal mehr wie 100ms, somit kommt er dann in den Loop, dass er nicht mehr Luft hat in der App auf Benutzeraktionen zu reagieren.
Würde der Thread mit dem Senden einer weiteren Nachricht warten, bis der MainThread 10ms Luft hatte wäre alles in Ordnung.

Wir reden aber auch von 5MB, die der Thread in 100ms zerlegen muss.
Das sind einfach sehr viele Daten.
Binary Daten werden auch auf der HDD zwischengespeichert.
Ich habe eine NVME, es gibt sicherlich aber auch noch HDD Benutzer. Somit dauert das Schreiben hier auch wieder länger.

Je höher das Intervall auch ist, desto länger Freezed die Anwendung ja auch bei der Verarbeitung von einem Block.
Deswegen passt 100ms ganz gut, da merkt der Anwender in der Regel nix... In der Regel aber halt nur

Ich habe auch eine Datenpool Klasse die Threadsafe Daten aus dem Thread aufnehmen kann und im MainThread anzeigen kann.
Als Darstellung nutze ich den VirtualStringTree.
Jede Zelle die er zeichnet, setzt eine Sperre auf den Pool, was auch nicht so performant ist.

Letztendlich habe ich mich aktuell dazu entschieden, die Daten via Message zu übertragen, weil die Performance dabei einfach besser ist und ich nicht so viele Locks produziere. Der Austausch der Daten via TOmniValue funktioniert hervoragend und auch sehr performant.

Wir reden hier generell vom Zeiten, die mich stören.
Der Endanwender wäre mit beiden Lösungen sicherlich zufrieden.

Vom Prinzip stört mich einfach, dass hier ein Bottleneck ist, was ich nicht beziffern kann.
Ich kann nur "meinen Computer" als Basis für die Zeit nehmen.

Aus unserer Diskussion schließe ich aber, dass es scheinbar nichts in der OTL gibt.

Eine Boolean Variable "Paused" im Task würde ja das Problem schon lösen, sowas werde ich sicherlich auch einbauen.

Danke für Deine Hilfe ...

Ja genau.

Wenn dein Hauptthread nur so viel Daten aus dem Thread nimmt, wie er verarbeiten kann und dann immernoch etwas Zeit hat,
oder er nimmt sich z.B. 20 Dinge aud dem Array/Queue raus und macht dann immer mal einen kurzen Sleep Delay)
dann läuft der Cache (dein Array/Queue) zwar langsam voll, wenn mal zu viel rein kommt, aber das Programm reagiert immernoch.

Andersrum kann der Thread aber auch langsamer werden, bzw. immer mal kurz pausieren, wenn der Hauptthread nicht mehr kann.


Oder kombiniert ... der Hauptthread macht so schnell wie er kann (nimmt sich z.B. alle 100ms so viel raus, wie er in weniger als dieser Zeit schafft) und der Thread pausiert, wenn ihm der Cache (Array/Queue) viel zu voll wird.




ODER

Es verarbeitet nicht der Hauptthread, sondern ein weiterer Thread,
dann reagiert das Programm auch immer, weil der Hauptthread ja nichts anderes macht, also mit dir zu reden und auf dich zu hören.

Weitergehend könnte man vielleicht dann auch gleich mehrere Threads verarbeiten lassen.
Der eine Thread holt die Daten, ein/mehrere Threads holen sich immer mal was aus der Queue/Array und ackern gleichzeitig
und der Hauptthread versorgt die GUI und gibt deine Befehle an die Threads weiter.

Zitat von himitsu:

Ja genau.

Andersrum kann der Thread aber auch langsamer werden, bzw. immer mal kurz pausieren, wenn der Hauptthread nicht mehr kann.

Ja, das war ja eine ursprüngliche Frage.
Woher weiß ich, das der Hauptthread ausgelastet ist.

OnIdle prüfen
TApplicationEvents

z.B. Messen wie lang ein Verarbeitungsdurchlauf dauert
GetTickCount, QueryPerformanceCounter, TStopwatch oder sonstwas

oder die CPU-Auslastung des Hauptthreads messen
GetSystemTimes

Und da der Hauptthread ja auch nur ein Thread ist, ist es nicht verboten TThread zu benutzen, und dort gibt es seit 'ner Weile so Einiges
TThread.GetSystemTimes(...)
TThread.GetCPUUsage(...)
TThread.GetTickCount
TThread.GetTickCount64
Das sind ClassFunctions, also können genau so benutzt werden,
aber auch für Nicht-Klassenfunktionen, kann man sich einen "Dummy"-TThread geben lassen.
z.B. TThread.Current.ThreadID

Und falls jemand wissen will, wieviele Threads man machen kann
TThread.ProcessorCount
Oder man nehme etwas, was das für Einen übernimmt.
TWorkStealingQueue
TThreadPool bzw. TParallel
und vielleicht auch noch TTask statt TThread (wobei das hier ja nicht nöig wäre, aber für andere Anwendungsfälle erwähnt)