LabVIEW hohe CPU Auslastung

[A. R. (redegle)]

Hallo,

ich habe in LabVIEW ein Programm geschrieben, welches mir scheinbar 
grundlos eine CPU-Auslastung zwischen 10 und 20 % erzeugt.

Das Programm befindet sich im Anhang. Statt den BOOLs, welche auf FALSE 
stehen sind im realen Programm Bools der Oberfläche, welche jedoch auch 
alle FALSE sind.

Im Prinzip werden alle 10ms 4 casestrukturen nicht ausgeführt. Wie kann 
soetwas die CPU belasten?

Vielen Dank für alle Antworten.

EDIT: In den Datenleitungen oben befinden sich ca 12 MB. Diese sollten 
aber normal nicht neu alloziert werden. In einer anderen Case-Anweisung 
wird auch keine CPU-Last erzeugt.

[Robert K. (Firma: Projektleiter Medizinsoftware) (robident)]

Ohne jetzt wieder vom Leder zu ziehen: LabView ist ein Speicher und 
Rechenzeitverschwender, wie ich kaum einen zweiten kenne. Es ist müssig 
darüber zu diskutieren, welcher Hintergrundprozess das nun wieder 
verursacht. Vermutlich hat es mit Deiner APP wenig zu tun.

Kann sein, das Viech pollt irgendwas ab, prüft und aktualisiert die 
timer und die GUI.

Ich empfehle, Labwindows zu nutzen. Einfach den unnützen overhead weg 
und frisches C/CPP eingesetzt.

[A. R. (redegle)]

>LabView ist ein Speicher und Rechenzeitverschwender, wie ich kaum einen zweiten 
>kenne.

Da stimme ich dir schoneinmal zu!

>Ich empfehle, Labwindows zu nutzen. Einfach den unnützen overhead weg
>und frisches C/CPP eingesetzt.

Es geht gerade darum, LabVIEW einzusetzten, um Einarbeitungszeit zu 
reduzieren. Deswegen kommt das leider nicht in Frage.

>Kann sein, das Viech pollt irgendwas ab, prüft und aktualisiert die
>timer und die GUI.

Hast du eine Idee, wie man rausbekommen könnte, was das Programm genau 
macht? Das darf doch nicht sein, dass ein polling oder ähnliches 10% der 
CPU braucht.

[Uwe (Gast)]

> Das darf doch nicht sein, dass ein polling oder ähnliches 10% der
> CPU braucht.
Klar deshalb benutzt man ja auch kein polling.

[A. R. (redegle)]

>> Das darf doch nicht sein, dass ein polling oder ähnliches 10% der
>> CPU braucht.
>Klar deshalb benutzt man ja auch kein polling.

Wo in dem Programm verwende ich polling?

[Morz Kerl (Gast)]

Naja, die 500 Threads die innerhalb Labviews vor sich hin werkeln 
verbraten diese Zeit.
Ich wuerd das auch  Labview auf die Halde werfen. Sofern man keine 
Treiber fuer komplexe Messgeraete benoetigt, ist es eh unsinnig. 
Brauchst du solche Treiber ?

[A. R. (redegle)]

>Naja, die 500 Threads die innerhalb Labviews vor sich hin werkeln
>verbraten diese Zeit.

Falsch. Die 500 Threads wenn es so viele sind erzeugen im Task-Manager 
eine Auslastung von 0%.

>Brauchst du solche Treiber ?

Spielt das eine Rolle? Ich habe lediglich gefragt, warum LabVIEW in 
diesem Programm so viel CPU-Auslastung erzeugt. Schon nach meinem 
zweiten Post hätte klar sein müssen, dass ich nicht auf LabVIEW 
verzichten möchte. Ich wollte nicht darüber diskutieren ob LabVIEW die 
beste Lösung ist oder nicht und ja es werden A/D-Wanlder-Karten von 
National Instruments eingesetzt.

Mittlerweile habe ich die Ursache für die hohe Auslastung entdeckt. 
Scheinbar ist es so, dass jede Verzweigung einer Datenleitung in LabVIEW 
im Hintergrund eine neue Allozierung des Speichers erzeugt. Das ist in 
der Aufbaustruktur von LabVIEW begründet muss man aber vorher einmal 
wissen. Diese Allozierung findet auch dann statt, wenn die Daten später 
nicht mehr benötigt werden. Z.B. wenn Sie nur auf eine CASE-Struktur 
geführt werden, die nicht ausgeführt wird.

[Tobias (Gast)]

Du kannst dir auch eine Referenz auf dein Anzeigelement erzeugen, diese 
dann weiterreichen und nur bei Bedarf in den Casestrukturen über die 
Eigenschaften von der Referenz auf die Werte zugreifen.
Das dürfte dir, wenn deine Case-Fälle in den meisten Fällen false sind, 
eine Menge kopierter Daten sparen.
Kleine Warnung: Die Referenz funktiniert so in etwa wie ein Pointer, mit 
den meisten Vor-und Nachteilen davon.

[chr (Gast)]

ersetze mal die "Uhr" in deinem Plan durch das "Metronom" und setz wenns 
geht die Zahl auf 20 oder 50.


Grüße

[ff (Gast)]

Und dann denk über das Konzept der Eventstruktur nach.

[maumau (Gast)]

Es zeigt die Hohe CPU-Auslastung nur, dass LabVIEW in der Lage ist hohe 
Systemresourcen anzufordern. Das bewirkt, dass die While-  Schleife viel 
schneller durchlaufen wird, als bei einem Mikrocontroller. Daher kannst 
Du die Kommtentare "ab in die Tonne" vergessen.
Durch die Verlagerung der Warteschleife wird der Task an den Scheduler 
zurückgegeben. Es ist keine "dumme" Warteschleife, die Systemresourcen 
verbraucht sondern eine Abgabe des Task.
Bitte schreib uns, ob die im Bild angegebene Lösung passt.

[Robert K. (Firma: Projektleiter Medizinsoftware) (robident)]

maumau schrieb:
> Es zeigt die Hohe CPU-Auslastung nur, dass LabVIEW in der Lage ist hohe
>
> Systemresourcen anzufordern.

Das macht ein altes 16 Bit Programm unter DOS auch, wenn ich es starte -
es rennt und rennt und blockiert den gesamten Rechner

[maumau (Gast)]

Aber mit der Funktion ("warten") kannst Du in LabVIEW den Task 
zurückzugeben Für andere Programme sind dann Resourcen frei. Bei einer 
Wartezeit von 1ms geht die Systemauslastung auf ca. 1% zurück.
Das war aber bei 16 Bit Systemen in WIN3.11 unmöglich. Das hat der 
Taskmanager bei einer Endlosschleife nicht weitergeschaltet.
Also hat robinet zwar recht mit "läuft und läuft", aber so ist es nicht 
in LabVIEW.

[Tobias (Gast)]

moep, der Threadersteller antwortet eh nicht mehr
und @maumau - deine Idee würde mal so gar nichts am Programmablauf 
ändern. So viel zu "ab in die Tonne" ;-)

[A. R. (redegle)]

>Du kannst dir auch eine Referenz auf dein Anzeigelement erzeugen, diese
>dann weiterreichen und nur bei Bedarf in den Casestrukturen über die
>Eigenschaften von der Referenz auf die Werte zugreifen.
>Das dürfte dir, wenn deine Case-Fälle in den meisten Fällen false sind,
>eine Menge kopierter Daten sparen.
>Kleine Warnung: Die Referenz funktiniert so in etwa wie ein Pointer, mit
>den meisten Vor-und Nachteilen davon.

Danke für den Hinweis.

>Durch die Verlagerung der Warteschleife wird der Task an den Scheduler
>zurückgegeben. Es ist keine "dumme" Warteschleife, die Systemresourcen
>verbraucht sondern eine Abgabe des Task.
>Bitte schreib uns, ob die im Bild angegebene Lösung passt.

Danke für den Hinweis. Das werde ich ggf. dem nächst mal Prüfen. Jedoch 
wurde das Problem schon damit gelöst, dass ich Verzweigungen von den 
Datenpfänden vermieden habe. Danach ging die Auslastung auf ca. 0% 
zurück.
Also im angehangenem Bild habe ich statt den rot gekennzeichneten 
Verzweigungen einen Aufbau wie in blau gekennzeichnet verwendet.


>moep, der Threadersteller antwortet eh nicht mehr
>und @maumau - deine Idee würde mal so gar nichts am Programmablauf
>ändern. So viel zu "ab in die Tonne" ;-)

Sorry, für mich war das Problem so weit erledigt und der letzte Beitrag 
den ich gesehen habe war von Tobias am 12.07.2012 um 10:24 Uhr.