Design einer komplexen Software: Multithreading oder nicht...

[grl]

Tag!

In einer Applikation (entwickelt mit D7/XP) werden vereinfacht gesagt Daten von einer externen Quelle aufgezeichnet, aus den aufgezeichneten Daten verschiedene Wertefolgen berechnet und diese über ein TChart angezeigt.

Mit steigender Komplexität der Software wird das Berechnen und anzeigen immer mehr zu einem Performance-Problem. Für's aufzeichnen der Daten und für diverse andere Hintergrundaufgaben wende ich sehr erfolgreich Threads an. Threads verwende ich generell sehr viel und erfolgreich, ich gehe daher davon aus daß der Thread-Design grundsätzlich korrekt und ohne Engpässe gelöst ist.

Für den Komplex Berechnung/Anzeige hab ich bisher zwei Wege gefunden:
1.) Berechnung in einem Thread, einfügen der Punkte ins TChart via Synchronize direkt aus dem Thread.
2.) Berechnen und anzeigen direkt im MainThread.

1.) hat den Vorteil, daß die Berechnung im Hintergrund passiert, allerdings ist das Zeichnen selbst so zeitaufwändig, daß es unterm Strich nicht viel schneller ist als die Variante 2. Das scheint allerdings an der TChart-Komponente zu liegen, denn ich die Werte statt in einem TChart einfach als Werte anzeige, ist das ganze so wie ich mir das vorstelle.
2.) ist vom Design her einfacher und muss nicht synchronisiert werden. Bei großen Datenmengen ist allerdings Geduld angesagt...

Daher meine Fragen:

1.) Wie würdet ihr sowas lösen bzw. wie würdet ihr das Zusammenspiel Berechnungsthread/MainThread lösen?
2.) Kann jemand eine gute Komponente empfehlen, mit der sich ein LineChart realisieren lässt, die nicht so überfrachtet und daher langsam ist wie TChart?


Über Tips dankbar,

Luggi

[Daniela.S]

Ohne jetzt die Struktur dahinter zu kennen, würde ich es so probieren:
Die Berechnungen in Threads aufzuspalten (je nachdem wie viele Sinn machen) und die einzelnen Ergebnisse vorerst im jeweiligen Thread abzulegen. Wenn dann alles abgearbeitet ist baut der MainThread dann das Chart auf...

Synchronize kostet auch relativ viel Zeit. Wenn es zu oft aufgerufen wird, dann dauert es unterm Strich womöglich länger das Chart als wenn alles im MainThread erledigt wird.

[Luckie]

Zitat von Daniela.S:

Synchronize kostet auch relativ viel Zeit. Wenn es zu oft aufgerufen wird, dann dauert es unterm Strich womöglich länger das Chart als wenn alles im MainThread erledigt wird.

Wenn es nur um eine Berechnung geht und es nur einen zusätzlichen Thread gibt, dann beschleunigt ein Thread gar nichts. Es sorgt nur dafür, dass die Benutzeroberfläche noch bedienbar bleibt.

[Sir Rufo]

Wenn es die Delphi/Pascal Version hergibt, dann auch mal alternativ Queue benutzen, das blockiert den Thread nicht

[FredlFesl]

Also ich würde mir zunächst überlegen, wie oft und genau die Daten visualisiert werden müssen. Muss ich ALLE Daten sehen, oder kann ich für die Visualisierung z.B. Daten verdichten, z.B. je Sekunde usw. Beim "wie oft" könnte als Ergebnis z.B. 500ms oder 2 Sekunden herauskommen. Dann würden die Daten eben 2x pro Sekunde oder alle 2 Sekunden aktualisiert dargestellt werden. Danach richte ich das Design des Hintergrundthread aus.

Der/die Hintergrund-Thread(s) nimmt die Daten entgegen und verdichtet entsprechend der Vorgaben verdichtet stellt die Daten bereit. Die darzustellenden Daten werden dann der Hauptanwendung per Message mitgeteilt. Neuerdings geht auch ein 'Queue' statt 'Synchronize'.

"Synchronize" hat den Nachteil, das es den Thread blockiert.

Das sollte ohne Probleme flüssig funktionieren.

[Daniela.S]

Stimmt schon, aber ich gehe einmal davon aus, dass "steigende Komplexität" auch mehrere Berechnungsschritte, die sich parallelisieren lassen, beinhaltet.
Natürlich sollte eine Anwendung auch bedienbar bleiben...

[FredlFesl]

Pro echtem Kern ein Thread. Mehr Threads bringen nix.

[grl]

Danke für die Antworten - auch wenn die Diskussion ein bischen von Thema abgewichen ist.

Es geht darum, wie die Berechnung und das Display zusammenspielen - nicht wie viele Threads sinnvoll sind. Hier mit mehreren Threads zu arbeiten ist aufgrund der Berechnungen nicht sinnvoll.

Bzgl des Vorschlags mit der Verdichtung: Das ist insofern implementiert, daß zuerst mal geprüft wird, wie viele Punkte der Bildschirm überhaupt anzeigen kann - und nur die werden wirklich ganz zu Ende gerechnet und auch dargestellt. Hier ist glaube ich keine Optimierung mehr möglich.

Das mit dem vorher berechnen lassen und dann anzeigen (z.B. 20 Punkte rechnen und dann in einem Schwung anzeigen) hat den Nachteil, daß es so "ruckelig" wirkt - und das können die Benutzer nicht zu gut verkraften.

Ich wiederhole bzw. präszisiere daher nochmal meine Fragen:
1.) Wie würdet ihr sowas lösen bzw. wie würdet ihr das Zusammenspiel Berechnungsthread/MainThread lösen? Die Berechnung im Hauptthread machen und damit riskieren, daß das UI einfriert? Über eine Callback-Function bei Fertigberechnung des Punktes diesen vom MainThread zeichnen lassen? Oder doch über synchronize?

und, was ich auch sehr interessant finden würde, weil TChart einfach sensationell lahmar... ist:
2.) Kann jemand eine gute Komponente empfehlen, mit der sich ein LineChart realisieren lässt, die nicht so überfrachtet und daher langsam ist wie TChart?

Danke
Luggi

[Medium]

Eine einfache Liniengrafik würde ich einfach selbst auf ein Bitmap zeichnen, das dürfte das flotteste sein. Hat den Vorteil: Du kannst das Zeichnen selbst in einem Offscreenbitmap noch im Thread machen, dem Hauptthread signalisieren (SendMessage() nehm ich dafür gerne her), dass ein neues Bitmap fertig ist, und das Blittest du einfach auf deine Form. Schlanker geht's im Mainthread kaum.
Ich würde also dem Mainthread eine TList<TBitmap> geben, an die der Thread seine fertig gezeichneten Bitmaps anhängt (ggf. das Add() synchronzied), und jeweils eine Message an das Fenster schickt wenn eines dazu gekommen ist. Dies dann im Mainthread anzeigen und aus der Liste entfernen. Nen kleiner Bitmap-Fifo quasi.

Dann könnte man sogar noch so weit gehen, dass man berechnen/zeichnen in 2 Threads splitted (sinnig, wenn das Zeichnen doch etwas "hübscher" wird), so dass man dem Zeichnen-Thread einen Daten-Fifo in ähnlicher Weise wie dem Hauptthread die Bitmaps gibt, und dann zeichnen lässt. Vorteil bei Multicores: Berechnen und Zeichnen laufen parallel.