code in LabVIEW 2010 extrem langsam

Hallo,
mein Programm liest ein ASCII Messdatenfile (Tabelle mit max. 7 Spalten und einigen 10.000 bis 100.000 Zeilen) ein. Mit LabVIEW 8.5 dauert dieser Vorgang einige 100ms. Der gleiche Code benötigt zum Einlesen der Daten in LabVIEW 2010 SP1 einige Minuten (!). Woran kann das liegen? Ich habe verschiedenes probiert, d.h. (1.) zeilenweises Lesen der Daten mit gleichzeitiger Konvertierung, (2.) Einlesen des gesamten Textfiles mit anschließender zeilenweiser Konvertierung der ASCII-Zeichen und Zuordnung in ein Clusterarray, (3.) die LabVIEW-Funktion "Tabellen-String nach Array". Alle Versionen sind in LabVIEW 8.5 etwa gleich schnell (z.B. (2.) 330ms, (3.) 560ms). In LabVIEW 2010 SP1 benötigt der gleiche Code für dieses Datenfile über 400s. Es scheint irgendwie an den for-Schleifen zu liegen. Hat jemand eine Idee? Das Problem tritt sowohl mit Windows XP SP3, als auch in Windows 7 auf.
Vielen Dank und viele Grüße
s

VI + Beispieldatei?

Dann kann man testen...

Hallo Achim,
danke für die schnelle Antwort.
Das Programm heißt "Auswertung DBU.vi" und benötigt noch einige SubVi's ("Segmentanalyse.llb"). Die Daten stehen im file "data.txt".
Der "Fehler" tritt im Tab "Rohdaten" auf ("Daten aus Datei laden"). Links neben der Registerkarte steht die benötigte Zeit in ms ("x-y" ist die zeit der LabVIEW Funktion "Tabellen-String nach Array", "x-y 2" ist Dauer der zeilenweisen Konvertierung).
Vielen Dank und viele Grüße
s

Hallo s,

und jetzt noch eine Testdatei... ok, gefunden.

Glaubst du wirklich, mit diesem Paradebeispiel für unübersichtliche Programmierung einen Blumentopf gewinnen zu können?
Schon mal ans Aufräumen gedacht? SubVIs anlegen? Lokale Variablen minimieren? RubeGoldbergs entfernen? Verdeckte Funktionen/Drähte sichtbar machen? Style-Guidelines beachten?

Ein RubeGoldberg springt sofort ins Auge: Da wird ein Array in einen Cluster umgewandelt, dieser Cluster per Unbundle zerlegt, ein Element entnommen und die restlichen wieder in ein Array zusammengefügt (ohne die Reihenfolge zu ändern). Ein typischer Einsatzfall für DeleteFromArray...

Diese Schleife (unten mittig) gilt es zu optimieren:
   
Hier zerlegst du äußerst ungeschickt ein großes Array in mehrere Cluster-Arrays: auf denkbar ungünstige Art werden hier 6 Cluster-Arrays aufgebaut. Mach daraus ein subVI und optimiere es!

Mal ein (hoffentlich äquivalenter) Vorschlag:
   

Hast du deine 8.5er VIs schon einmal unter LabVIEW 2010 gespeichert und erst dann ausgeführt?
Zwecks Änderungen am Compiler-Unterbau von LabVIEW kann es zu solchen Effekten kommen, wie von dir beschrieben.

Gruß, Jens

Hallo GerdW,

sorry wegen dem etwas chaotischen code und danke für die Hinweise. Den Vorschlag werde ich integrieren.

Hallo jg,

die 8.5er Version habe ich auch als 2010er Version gespeichert und eine *.exe erzeugt. Es ändert leider nichts.

Viele Grüße
s

Nochmal Hallo GerdW,

mit der vorgeschlagenen Änderung geht es in LabVIEW 2010 jetzt genauso schnell (wenige 100ms).
Bleibt jetzt nur die Frage nach der Ursache. LabVIEW 8.5 ist hier scheinbar wesentlich toleranter mit unoptimiertem code. Der wesentliche Unterschied liegt m.E. in dem verschachtelten for-loop in meinem code und der einfachen Schleife in deinem Vorschlag. Warum geht das in LabVIEW 2010 nicht?

Vielen Dank und viele Grüße
s[/align]

Hallo s,

in LV2010 wurde der zugrundeliegende Compiler grundlegend geändert. Da können sich, insbesondere bei schlechtem Memoryhandling wie in deinem Fall, durchaus Änderungen am Verhalten des Compilats ergeben.

Aber die Whitepapers zum effizienten Umgang mit Speicheranforderungen galten auch schon zu Zeiten von LV8.5 - du hast sie nur nicht beachtet

Hallo GerdW,
nochmals danke für die konstruktive Kritik. Gibt es irgendwo eine übersichtliche Zusammenfassung von Optimierungsvorschlägen bzw. häufig auftretenden Unsinnigkeiten?
Leider bin ich nur ein "LVF-Grünschnabel" und habe LabVIEW nur so nebenbei "gelernt", ohne Lehrer oder Kurs.
Vielen Dank und viele Grüße
s

http://sine.ni.com/tacs/app/overview/p/a...8/id/1588/

Gruß Markus

(07.11.2012 08:16 )stsc schrieb:  Gibt es irgendwo eine übersichtliche Zusammenfassung von Optimierungsvorschlägen bzw. häufig auftretenden Unsinnigkeiten?