LabVIEWForum.de - Probleme mit der Rechenzeit

LabVIEWForum.de

Normale Version: Probleme mit der Rechenzeit
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3
Hallo

Man kann auch mal den Profiler laufen lassen:

Tools->Profile->Performance and Memory

Erst "Start" drücken, danach das VI starten.

Es werden alle Sub VIs aufgelistet mit benötigter Rechenzeit u.s.w.

Gruss, BDB
Hallo zusammen,
Schöne Sammlung von Performance Tipps.

Dusky
Welches Timing-Intervall musst du einstellen um auf 5:00 Minuten zu kommen und wie verhält sich dabei die Prozessorlast.
Wie schnell musst du sein ?

DaqMx betreffend: Samplingrate, Blockgröße, bzw. daraus resultierend die effektive Schleifendauer.

Als Tipp hätte ich noch ebenfalls wie BDB den LV eigenen Profiler Performance and Memory der Dir bestimmt bei der Suche
Nach Performance weiterhilft.

Gruß
Ralf
hey leute ihr seit super!
das performance tool bringts! Problem behoben, vi läuft flüssig!

für die interessierten: Ich hab i-wo n kleines subVi gehabt mit dem man sich ein neues benutzerprofil erstellen kann...durch den performancer hab ich festgestellt, dass es unter "am meinesten ausgeführt" auf platz 1 war mit nem vorsprung von knapp 900% zu dem auf platz 2Wink

ich danke euch allen - jetzt gibts hier, wie rasta schon anmerkte - mal ne richtig solide sammlung für speed control

liebe grüße, schönen feierabend,
Dusky
' schrieb:also ich komme mit einer ungebremsten schleife die nur einen zufallswert anzeigt schon von meinen üblichen 3% auslastung hoch auf über 60%!
Auch wenn das Problem inzwischen gelöst ist, genau so was meine ich mit Wahnsinn. While-Schleife, die z.B. ohne Wait-Funktion auf irgendein Ereignis wartet. Führt sofort zu 100 % CPU-Auslastung (ok, du hast wahrscheinlich eine Dual-Core, dann also zu den 60%). Wie IchSelbst gesagt hat, bei mehr als 10% Dauer-CPU-Belastung läuft irgendetwas verkehrt!

Gruß, Jens
' schrieb:Wie IchSelbst gesagt hat, bei mehr als 10% Dauer-CPU-Belastung läuft irgendetwas verkehrt!

Gruß, Jens

Auch meine Meinung. Eine normale Applikation sollte keinesfalls mehr verbraten, denn es müssen Ressourcen da sein, um auch Peaks abzufangen und du weißt nie, was der User noch so alles machen will/muss. Um herauszufinden, wie sich ein App in Bezug auf Speicher etc. verhält ist imho der ProcessExplorer erste Wahl.
Hallo,
da bei mir nun alle schwierigkeiten überwunden sind, möchte ich nochmals für alle, die evl ähnliche performance probleme haben/bekommen, noch einen guten zusammenfassenden tipp geben, der sich aus den beiträgen dieses topics zusammensetzt!

- schritt 1: in die main-schleifen "uhr"-funktion einbauen und schauen, in welcher schleife die zeit laggt (ruckt, unregelmäßig läuf oder
gar stehen bleibt)

- schritt 2: "Performance Manager" laufen lassen
-> SubVis die unnötig oft ausgeführt werden raussuchen und neu ein das programm einbinden
-> SubVis die überhöhte bearbeitungszeit beanspruchen re-codieren

- schritt 3: Timer in schleifen einbauen mit konstanten von mind. "10" bis etwa "100" (oder bis zu "500" - je nach art des VIs)

- schritt 4: "Global Vars" durch "Local Vars" ersetzen - besser noch durch "eigenschaftsknoten"

- schritt 5: Lieber ein oder zwei große arrays als viele kleine

- schritt 6: Möglichst viele "ereignisschleifen" einbauen und dafür "while" und "case" rausschmeißen

----> wenn noch immer nich besser geworden ist...rechner kaputt hauen!

liebe grüße,
Dusky
Hallo Dusky

Dafür wirst Du Dir sicher einige Protestschreiben einfangenRolleyesRolleyes
Wieso? wegen des kaputten rechners? oder weil ich eure beiträge zusammen gefasst habe? --> hab extra erwähnt, das es eine zusammenfassung aller beiträge ist! will niemanden auf die füße treten!

ich denke noch immer, dass das ein guter überblick für performance in LabVIEW ist
Zusatz:

' schrieb:- schritt 3: Timer in schleifen einbauen mit konstanten von mind. "10" bis etwa "100" (oder bis zu "500" - je nach art des VIs)
Schritt ist notwendig, wenn durch genau diese Schleife die Prozessorauslastung auf z.B. 99% steigt.
Schritt ist nicht notwendig, wenn indirekte Zeiten vorhanden sind: Warten auf Melder/Queue/DaqMX-Read etc.

Zitat:- schritt 4: "Global Vars" durch "Local Vars" ersetzen - besser noch durch "eigenschaftsknoten"
Eigenschaftsknoten haben mehr Nachteile als Vorteile. In manchen Fällen kann ein Value-Property aber genau richtig sein.
Am allerbesten ist immer Datenfluß, auch wenns manchmal kompliziert ist und aussieht. Danach kommen sog. "funktionale globale Variablen". Normale Globale Variablen kann man immer ersetzen.

Zitat:- schritt 5: Lieber ein oder zwei große arrays als viele kleine
Array-Handling ist immer kompliziert. Bedenke: Bei Funktionen wie "In Array einfügen" etc. - also Funktionen, die die Arraygröße ändern - wird das gesamte Array umkopiert. Und dieses Kopieren verbraucht Platz und Zeit. Daher: Auf Funktion "in Array ersetzen" umsteigen. Dann ist es auch egal, ob das Array groß oder klein ist. Wichtiger als die Größe ist also das Management.
Hier noch einige Tipps (englisch) *improving_performance.pdf*
Seiten: 1 2 3
Referenz-URLs