AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Design einer komplexen Software: Multithreading oder nicht...

Design einer komplexen Software: Multithreading oder nicht...

Ein Thema von grl · begonnen am 4. Sep 2011 · letzter Beitrag vom 5. Sep 2011
Antwort Antwort
grl

Registriert seit: 5. Feb 2007
174 Beiträge
 
FreePascal / Lazarus
 
#1

Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 16:20
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
  Mit Zitat antworten Zitat
Benutzerbild von Daniela.S
Daniela.S

Registriert seit: 1. Mär 2008
Ort: Niederösterreich
224 Beiträge
 
Delphi XE4 Enterprise
 
#2

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 16:51
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.
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie
(Moderator)

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#3

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 16:53
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.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#4

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 16:54
Wenn es die Delphi/Pascal Version hergibt, dann auch mal alternativ Queue benutzen, das blockiert den Thread nicht
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
FredlFesl

Registriert seit: 19. Apr 2011
293 Beiträge
 
Delphi 2009 Enterprise
 
#5

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 16:54
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.
Das Bild hängt schief.
  Mit Zitat antworten Zitat
Benutzerbild von Daniela.S
Daniela.S

Registriert seit: 1. Mär 2008
Ort: Niederösterreich
224 Beiträge
 
Delphi XE4 Enterprise
 
#6

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 16:55
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...
  Mit Zitat antworten Zitat
FredlFesl

Registriert seit: 19. Apr 2011
293 Beiträge
 
Delphi 2009 Enterprise
 
#7

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 17:01
Pro echtem Kern ein Thread. Mehr Threads bringen nix.
Das Bild hängt schief.
  Mit Zitat antworten Zitat
grl

Registriert seit: 5. Feb 2007
174 Beiträge
 
FreePascal / Lazarus
 
#8

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 4. Sep 2011, 21:06
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
  Mit Zitat antworten Zitat
Medium

Registriert seit: 23. Jan 2008
3.676 Beiträge
 
Delphi 2007 Enterprise
 
#9

AW: Design einer komplexen Software: Multithreading oder nicht...

  Alt 5. Sep 2011, 09:22
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.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:44 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf