+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenerfassung (DAQ) (/Forum-Datenerfassung-DAQ)
+---- Thema: Probleme mit der Rechenzeit (/Thread-Probleme-mit-der-Rechenzeit)
Probleme mit der Rechenzeit - Dusky - 30.04.2009 13:56
Hallo liebe LabVIEWer
ich habe ein kleines problem, welches aber riesen folgen mit sich bringt.
Mein vi bekommt ein signal von einer brennkammer (über DAQ) - 4 kanäle mit einer frequenzbreite (x-achse) von etwa 7000 - und ich möchte die werte weiter verarbeiten. Nach gut 4 monaten arbeit ist mein programm endlich fertig und läuft einwandfrei...auf meinem eigenen rechner. Dummerweise ist das einer der besten, die es auf dem mark gibt, was ich nicht bedacht habe-.- Zurück beim dlr will ich mein vi nun auf den rechnern installen und muss feststellen, dass diese absolut überfordert sind.
Ich kann das vi hier leider nicht veröffentlichen, aber als kurzen einblick: Über 30 anzuzeigende graphen, 4 verschiedene glättungsmethoden, es gibt 2 verschiedene peak-finder, außerdem werden alle 2 min. 4x7000werte (2x X-werte, 2x Y-werte) gespeichert (Gesamtgröße mit SubVis ~20Mb).
ich habe mal eine uhr laufen lassen, diese stand nach 5,00 min. gerade mal bei 3:22. Nun habe ich versucht einige graphen zu deaktivieren und nicht berechnen zu lassen solange der Tab auf dem sie liegen nicht selektiert ist - dadurch hab ich aber lediglich eine erhöhung der rechenzeit erreicht (3:02) und nicht eine verrinderung.
Was habt ihr für gute ideen zur verringerung der rechenzeit..ich denke da vor allem an die wahl der schleifen (derzeit hab ich 2 parallel laufende WHILE , in denen eine menge CASE und SEQUENZ laufen), ist es besser alles auf eine WHILE zu kürzen und die unterschleifen in andere schleifen arten zu wandeln? Wenn ja, welche schleifen laufen besser?
Wäre super, wenn ihr ein paar tipps für mich hättet,
liebe grüße, Dusky
Probleme mit der Rechenzeit - schrotti - 30.04.2009 14:22
Hallo Dusky,
solche Probleme kenne ich von einigen Prüfständen, die ich "geerbt" habe. Bis jetzt war immer die Art und Weise schuld, in der der Programmierer ein Problem gelöst hatte. Polling, viele Kopien von Arrays anlegen etc.
Wie oft aktualisierst die Anzeigeelemente deines Frontpanels? Werden irgendwelche Funktionen unnötigerweise in jedem Schleifendurch ausgeführt? Ich denke da an "Start Task" und ähnliches. Wie schauts mit polling aus? Wie sieht die Speicherauslastung aus?
Probleme mit der Rechenzeit - Dusky - 30.04.2009 14:37
danke für dir schnelle antwort!
- also unnötige arrays schließe ich aus, die hab ich schon aufs minimale gekürzt, das war auch meine erste vermutung.
- wegen der aktualisierung...hm ich hab mittlerweile mein timing von 10milli sek auf 100 ehöht. Das brachte mich auf 3:55, is n guter anfang, danke
- speicherauslasung - laut task manager 81-95%
- "polling" das musst ich erstmal googlen^^ wenn ichs richtig vertehe dann ist damit die samplingrate gemeint, oder? Ich muss leider mit einer samplingrate von 10.000 arbeiten, die samples per second haben den selben hohen wert - nicht änderbar!
--> wie wirkt siche denn eine hohe nutzung der glob var aus?
Probleme mit der Rechenzeit - jg - 30.04.2009 14:46
' schrieb:- speicherauslasung - laut task manager 81-95%Speicherauslastung in % und nicht in MB???
Oder hast du jetzt nach CPU-Auslastung geschaut. Wobei 95% ein absoluter Wahnsinn sind...
Und bei Speicherauslastung meinste schrotti wohl eher, ob dein Progamm dauernd neuen Speicher alloziert?!
' schrieb:- "polling" das musst ich erstmal googlen^^ wenn ichs richtig vertehe dann ist damit die samplingrate gemeint, oder?"Polling": Fragst du dauernd irgendwelche Aktivitäten ab, liest dauernd irgendwelche Variablen aus, um auf etwas zu reagieren, anstatt wenn möglich auf Events zu setzen?
' schrieb:Ich muss leider mit einer samplingrate von 10.000 arbeiten, die samples per second haben den selben hohen wert - nicht änderbar!Kann übel daneben gehen, vor allem wenn du Globale Variable zum Array-Austausch verwendest.
--> wie wirkt siche denn eine hohe nutzung der glob var aus?
In globale Variablen gehören aus meiner Sicht allerhöchstens programmweite einfache Konfigurations-Parameter, die nach Möglichkeit auch nur einmal zu Start des Programms gesetzt werden.
Gruß, Jens
Probleme mit der Rechenzeit - Dusky - 30.04.2009 15:03
Huhu,
ja sorry, ich hab die % der cpu auslasung angegeben! was den speicher angeht: 600/1000mb scheint aber unabhängig davon zu sein, obs prog läuft oder nicht
zum polling: Ich denke da bin ich recht aktiv, aber sowas lässt sich ja auch schwer vermeiden. ich habe schon einige sachen neu formuliert: zb "x werte anhand der samplingrate berechen" so geschrieben, dass dies nur ausgeführt wird, wenn eine wertänderung bei "samplingrate" stattfindet. funktioniert gut, allerdings nicht beim start des programms, obwohl ich eigentlich beim start den wert automatisch einmal +/-1 schwanken lasse um die wertänderung für die ereignisstruktur hervorzurufen...
zu den variablen: wenn ich dich richtig verstehe, ists besser wenn ich lokal vars nutzte, ja?
Probleme mit der Rechenzeit - TSC - 30.04.2009 15:04
' schrieb:Speicherauslastung in % und nicht in MB???
Oder hast du jetzt nach CPU-Auslastung geschaut. Wobei 95% ein absoluter Wahnsinn sind...
also ich komme mit einer ungebremsten schleife die nur einen zufallswert anzeigt schon von meinen üblichen 3% auslastung hoch auf über 60%!
Probleme mit der Rechenzeit - Dusky - 30.04.2009 15:09
tschac, wenn du gerade versucht mich aufzubauen, is das der falsche ansatzt!
außerdem ist ne WHILE ohne timer auch nich die regel
Probleme mit der Rechenzeit - TSC - 30.04.2009 15:19
keine angst, wollte dich nciht aufbauen. war nur so ein gedankengang um "Jens G"s beitrag nachzuvollziehen (dass so ne hohe auslastung extrem wäre).
in meinen projekten verwende ich kaum zeitgesteuerte strukturen. meine schleifen werden in der regel durch funktionen wie "warte auf melder" oder soetwas pausiert und irgendwann eben gestartet. auch eventstrukturen reduzieren die cpu auslastung enorm. Aber ich weiß auch gar nciht so genau ob das hier in die diskussion so rein gehört. kenne mich da nciht so genau aus.
Probleme mit der Rechenzeit - oenk - 30.04.2009 15:52
' schrieb:zu den variablen: wenn ich dich richtig verstehe, ists besser wenn ich lokal vars nutzte, ja?
Für grosse Datenmengen (deine Arrays sind aller Wahrscheinlichkeit als gross anzusehen) eignen sich weder globale noch lokale Variablen. Sie beinhalten immer eine Kopie der Daten. Mach es mit dem Datenfluss, das ist in diesem Fall am Resourcensparendsten.
zu globalen Variablen gibt es hier eine recht gute Diskussion wann und wie sie verwendet werden können.
Probleme mit der Rechenzeit - IchSelbst - 30.04.2009 16:01
' schrieb:ja sorry, ich hab die % der cpu auslasung angegeben!Also 80% CPU-Auslastung durch das LV-Programm? Das ist um mindestens 60% zu viel. Die Leerlaufauslastung kann bei 80% (besser 95%) liegen. Das ist dann gut.
Zitat:was den speicher angeht: 600/1000mb scheint aber unabhängig davon zu sein, obs prog läuft oder nichtGesamtspeicherauslastung von 1GB? Und wieviel Speicher verbraucht das LV-Programm.
Was sich bei mir immer als Zeitfresser herausstellt, ist folgendes:
Dauerndes (z.B. in While-Schleife für Schieberegister) "Array erstellen". Im Allgemeinen solche Array-Funktionen, die die Array-Größe ändern. Abhilfe "In Array ersetzen"
Refresh am Frontpanel. 250ms sich ausreichend.
Ausgabe an Graphen. Je nach Kompexität kann das Darstellen im Graphen schon mal 500 ms dauern.
While-Schleifen, auch solche die pollen, hab ich mit 50ms laufen.
Unkritisch scheint mir zu sein:
While-Schleifen zum Abfragen von Bedienelementen sind zwar unkritisch. Ich hab sie aber mittlerweile alle durch Event-Cases ersetzt.
Ich hab so um die 10 parallele SubVIs laufen. Alle in 50ms zum DAQmx-Samplen. Ich kann nichts negatives feststellen.
Auch bei jeder Menge Queues und Melder hab ich keine Nachteile festellen können.
Noch ein Wort zu den Globalen Variablen:
GV an sich, finde ich, sind sehr schön. Nur nicht in LV. Daher: FGV. Damit sind die Daten global vorhanden, aber eben nicht im Format einer GV, sondern im Format eines SubVIs, das in den Datenfluß eingebunden werden kann.