Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich stecke in der Materie Labview noch nicht allzu lange drin aber bei meinem momentanen Problem konnten mir auch erfahrenere Kollegen noch keine richtige Hilfestellung geben.
Zunächst noch folgende Info: Ich nutze Labview 10.0 32Bit unter Windows 7 64 Bit.
Zu meinem Problem: Ich habe ein kleines Programm geschrieben, welches aus einem angewählten Ordner sämtliche Dateien einer bestimmten Endung öffnet, durchparst und ihre Bestandteile auswertet und ausgibt. Beim Durchlaufen habe ich festgestellt, dass der Rechner die ersten Dateien (@ ca. 1,7MB) noch sehr rasch abarbeitet. Werden es mehr Dateien, so wird die Bearbeitungszeit deutlich länger. Ich habe schon verschiedene Performancemessungen durchgeführt und habe so langsam keinen Schimmer mehr was ich noch tun könnte. Auch die Prioritäten habe ich beim Kompilieren schon erhöht, leider ohne nennenswerte Erfolge. Alles hat ein wenig den Eindruck als würde eine Art Speicher volllaufen, jedoch wird die Bearbeitungszeit pro Datei nach ca. 3-4 Dateien auch wieder ein wenig besser, bevor sie sich wieder verschlechtert ?!? ...kann es sein dass Windows dem Ganzen einen Riegel vorschiebt?
Hier sind kurz die Ergebnisse zu sehen wenn ich ein und die selbe Datei (mehrfach in einem Ordner kopiert) durch das Programm jage:
Zitat:1 815 ms @ 1655153 Bytes
2 872 ms @ 1655153 Bytes
3 835 ms @ 1655153 Bytes
4 886 ms @ 1655153 Bytes
5 808 ms @ 1655153 Bytes
6 865 ms @ 1655153 Bytes
7 879 ms @ 1655153 Bytes
8 912 ms @ 1655153 Bytes
9 984 ms @ 1655153 Bytes
10 865 ms @ 1655153 Bytes
11 844 ms @ 1655153 Bytes
12 835 ms @ 1655153 Bytes
13 878 ms @ 1655153 Bytes
14 1035 ms @ 1655153 Bytes
15 837 ms @ 1655153 Bytes
16 894 ms @ 1655153 Bytes
17 896 ms @ 1655153 Bytes
18 975 ms @ 1655153 Bytes
19 972 ms @ 1655153 Bytes
20 988 ms @ 1655153 Bytes
21 939 ms @ 1655153 Bytes
22 991 ms @ 1655153 Bytes
23 1092 ms @ 1655153 Bytes
24 1114 ms @ 1655153 Bytes
25 1147 ms @ 1655153 Bytes
26 1285 ms @ 1655153 Bytes
27 1225 ms @ 1655153 Bytes
28 1075 ms @ 1655153 Bytes
29 1227 ms @ 1655153 Bytes
30 1279 ms @ 1655153 Bytes
31 1184 ms @ 1655153 Bytes
32 1277 ms @ 1655153 Bytes
33 1244 ms @ 1655153 Bytes
34 1202 ms @ 1655153 Bytes
35 1460 ms @ 1655153 Bytes
36 1309 ms @ 1655153 Bytes
37 1166 ms @ 1655153 Bytes
38 1307 ms @ 1655153 Bytes
39 1372 ms @ 1655153 Bytes
40 1223 ms @ 1655153 Bytes
41 1351 ms @ 1655153 Bytes
42 1344 ms @ 1655153 Bytes
43 1280 ms @ 1655153 Bytes
44 1395 ms @ 1655153 Bytes
45 1327 ms @ 1655153 Bytes
46 1286 ms @ 1655153 Bytes
47 1434 ms @ 1655153 Bytes
48 1396 ms @ 1655153 Bytes
49 1306 ms @ 1655153 Bytes
Anbei noch ein kleiner Teilausschnitt meines Sub-VI welches von außen durch eine While-Schleife umrahmt:
Kann mir jemand helfen und erklären warum mein Rechner mit zunehmender Anzahl von Dateien anfängt zu schwächeln bzw. mir erklären ob ich einen systematischen Fehler begehe?
Vielen Dank und Viele Grüße
waldguru82
Anzeige
17.08.2011, 08:58 (Dieser Beitrag wurde zuletzt bearbeitet: 17.08.2011 09:16 von Lucki.)
Poste doch für den Anfang wenigstens mal den Code in der ersten Sequenz als VI, dort steckt doch schon der Wurm drin. Und dazu einen kleinen Auszug aus der zu untersuchenden Textdatei. Das würde die Beantwortung enorm erleichtern.
Edit: Dein Programm liest nur eine einzige Datei, und Du hast keine Schleife im Programm, um Deine vielen Dateien auf einmal zu untersuchen. Sind Deine Ergebnisse also so zu interpretieren, daß Du das VI wegen jeder Datei ganz neu startest, und trotzdem hat man die zunehmend sich vergrößernde Bearbeitungzeit?
danke für Deine Antwort. Um etwas zu posten müßte ich den mittlerweile entstandenen Spaghetticode noch kurz entschlacken und würde den Code dann mal zur Verfügung stellen... das dauert allerdings noch einen kleinen moment... (Terminfracht an anderer Baustelle).
und Ja, Du hast Recht... es handelt sich dabei um ein Sub-VI welches von außen über eine While-Schleife immer wieder angestoßen wird. Die Ausgabevariablen werden zwar in ein Schieberegister gegeben aber daran allein liegt es nicht, da ich das Schieberegister in meiner Testschleife immer wieder mit einem Leerstring beschrieben wird. Kannst Du mit diesen Informationen vorab schon was anfangen?
Kleiner Hinweis für zwischendurch:
Versuchs doch mal mit "Speicherfreigabe anfordern" im SUB-VI. Habe allerdings selbst keine Erfahrungen damit. (Möglicherweise ist es eher für den Fall gedacht, dass ein SubVI später nie wieder aufgerufen wird.)
In: Applikationssteuerung --> Speicherverwendung
Ich halte auch die Benutzung einer Queue in der ersten Sequenz nicht für optimal. Und schon gar nicht, daß diese Queue bei jedem Aufruf des Sub-VI neu erstellt und wieder geschlossen wird. Wenn schon mit Queue, dann Erstellen und Schließen einmalig im Haupt-VI, und im SubVI nur das Hinzufügen/Entfernen von Elementen machen. Aber, wie schon gesagt, besser hier gar keine Queue nehmen.
das mit der Speicherfreigabe ist zumindest teilweise behoben. Die Frage ist: Wenn keine Queues, was sollte ich dann nehmen?
Die Bearbeitungsschritte sehen im Wesentlichen so aus, dass ich zunächst meine Messdatei zeilenweise in eine Queue einlese (jede Zeile ein Messwert von einem unwillkürlich ausgewählten Signal)... danach, nehme ich das Array aus der Queue und öffne 4 neue Queues, wo ich die Messwertinhalte nach ihren Kanälen (jede Queue ein Messkanal) aufteile usw. usf.
Die Queue bietet sich dazu förmlich an aber scheint laut Deiner Aussage nicht besonders speichergünstig zu sein... wie könnte denn eine ressourcenschonendere Alternative aussehen?
Du könntest dir die erste Sammelqueue schonmal komplett sparen, wenn du einen gefunden Substring einfach direkt in die richtige Kategorie einordnest.
Damit würdest du die zweite Forschleife auch shcon sparen, da du direkt bei einem Pfund den CAN-String in die Bestandteile zerlegen könntest. Das Ergebnis untersuchst du dann auch noch direkt und packst es in die entsprechende Zielqueue.
Wenn du die Größe der Datei kennst, kannst du nicht die maximale Anzahl der zu verwertenden CAN-Borschaften berechnen?
Dann könntest du entsprechende Arrays benutzen, falls Speicher kein Problem ist.
Wenn du dazu noch die Anzahl der jeweiligen Channelelemente kennst, kannst du schon ziemlich effektiv mit nem Array arbeiten und hast nur eine Forschleife im Programm.
Anzeige
17.08.2011, 15:03 (Dieser Beitrag wurde zuletzt bearbeitet: 17.08.2011 15:09 von Lucki.)
(17.08.2011 14:16 )waldguru82 schrieb: Die Queue bietet sich dazu förmlich an aber scheint laut Deiner Aussage nicht besonders speichergünstig zu sein...
Das wollte ich damit nicht sagen. Außerdem geht es hier doch gar nicht um Ressourcen, sondern um die Ausführungszeit.
Und dazu läßt sich allgemein sagen: Bei der Verarbeitung größerer Arrays entstehen immer dann hohe Verarbeitungszeiten, wenn man Labview nicht von vornherein sagt, welche maximale Größe das Array haben kann. LV muß dann den standardmäßig reservierten Memorybereich zur Laufzeit vielfach nach oben korrigieren, und das kostet enorm Zeit.
Ich vermute, daß deine Queue schon schneller wird, wenn Du im VI "Queue anfordern" eine Maximalgröße der Queue angegeben hättest. So aber tappt LV im Dunkeln.
Queues würde ich hier nur deshalb nicht nehmen, weil sie u.a. eigentlich mehr für den Austausch von Daten in parallelen Prozessen gedacht ist. Hier aber sehe ich keinen Vorteil gegenüber anderen Methoden.
Um Dir auf einfache Art eine Alternative vorzuschlagen, hatte ich Dich gebeten, die erste Sequenz des VIs mal zu posten. Aber das soll wohl nicht sein. Hier trotzdem ein Vorschlag.
Das Prinzip ist: Das neue Array wird mit dem alten Array vorinitialisiert. In der Schleife werden diese Elemente, von unten beginnend, durch die gefundenen Zeilen ersetzt. Nach Beenden der Schleife werden die nicht ersetzten oberen Zeilen abgeschnitten.
vielen Dank für Eure Antworten. Sorry, dass ich mich erst so spät melde aber die Toolerstellung läuft bei uns eher nebenbei und ich hatte leider eine Terminfrist, die es mir nicht ermöglichte mich ausführlicher mit meiner hier geposteten Problematik zu beschäftigen. Sorry auch dafür, dass ich meinen Code nicht gleich zur Verfügung gestellt habe aber nach all dem Rumprobieren hatte ich irgendwie die Vermutung nur noch wüsten Spaghetticode erzeugt zu haben, welchen ich niemanden zumuten wollte.
Das mit dem Array und der vordefinierten Größe hatte mir performancetechnisch auf jeden Fall einige Punkte gebracht, jedoch war die Grundproblematik immer noch nicht behoben... die stelle an der mein Programm anfing zu lahmen war nun nicht mehr Datei No. 10 sondern datei No. 25.
Nun habe ich aus lauter Verzweiflung noch ein wenig mit dem Code rumgespielt und bin zu einer zweifelhaften Lösung gekommen, die jedoch zu funktionieren scheint:
Bei der Queue anfordern-Funktion habe ich den Eingang "Erzeugen, wenn nicht gefunden" (standardmäßig auf True gestellt) einfach mal spaßeshalber bei all meinen Queues auf "False" gestellt. Und was soll ich sagen: mit kleinen Varianzen in der Abarbeitungszeit läuft das Programm unabhängig von der Dateianzahl gleichschnell durch.
Nun die Frage: WARUM?
Nach meinem Empfinden und meiner Logik nach dürfte das Programm mit dieser Option gar nicht funktionieren. Handelt es sich dabei um einen Dokumentationsfehler oder bin ich einfach nur zu blöd zu verstehen was ich da eingestellt habe? Wie auch immer, das Programm läuft nun wie gewünscht
Vielen Dank an dieser Stelle für Eure trotzdem durchaus fruchtbare Hilfe. Ich werde versuchen beim nächsten mal ein wenig mehr "Futter" zu reichen um die Erörterung der Problematik ein wenig voranzutreiben.
(22.08.2011 15:43 )waldguru82 schrieb: Bei der Queue anfordern-Funktion habe ich den Eingang "Erzeugen, wenn nicht gefunden" (standardmäßig auf True gestellt) einfach mal spaßeshalber bei all meinen Queues auf "False" gestellt. Und was soll ich sagen: mit kleinen Varianzen in der Abarbeitungszeit läuft das Programm unabhängig von der Dateianzahl gleichschnell durch.
Nun die Frage: WARUM?
Nach meinem Empfinden und meiner Logik nach dürfte das Programm mit dieser Option gar nicht funktionieren. Handelt es sich dabei um einen Dokumentationsfehler oder bin ich einfach nur zu blöd zu verstehen was ich da eingestellt habe? Wie auch immer, das Programm läuft nun wie gewünscht
Prinzipiell finde ich die Idee für die Aufgabe Queues zu benutzen gut. Aber ich kann es mir einfach nicht vorstellen, das dein Programm mit nicht angelegten NamedQueues einen _validen_ Output generiert.
Die Readline Funktion ist recht lahm... 1 Sekunde für 1.5 MB ist eindeutig zu lahm.
Anbei eine kleine Parserspielerei mit Testdaten.
testdata.zip (Größe: 1,53 MB / Downloads: 246)
nachdem ich gestern ziemlich siegessicher der Meinung war das Problem entlarvt zu haben, wurde ich mit dem Stichwort der Validität eines Besseren belehrt *peinlich* ...zumindest habe ich den Status der Lösung erstmal wieder aufgehoben.
@macmarvin, Vielen Dank für Dein Programmbeispiel aber irgendwie werde ich noch nicht so ganz schlau daraus was ich dem Ganzen für meine Problematik entnehmen kann. Ich habe mal ein kleines Beispielprogramm geschrieben mit welchem die ganze Problematik immer noch auftritt... hängt im Anhang mit einer kleinen Testdatei. Der Initialaufwand besteht darin, die ASC-Datei ca. 1000 mal zu kopieren (ich wollte aus speicherplatzgründen nicht den ganzen Ordner dranhängen.
Bei dem ungefähr 500. Durchlauf fängt die Performance an zu schwächeln... manchmal etwas früher, manchmal auch etwas später. Kann mir jemand sagen was ich an dieser Stelle falsch mache bzw. noch verbessern könnte? Ich habe den Eindruck, dass sich die Performance, wenn ich der Queue eine maximale Länge zuweise, noch verschlechtert... muss aber auch nicht so sein. Irgendwie ist mir diese Problematik insgesamt etwas schleierhaft. Bitte schaut Euch das mal an und gebt Euren Senf dazu (dass sich eine Schleife mit füllendem Schieberegister verlangsamt ist mir klar, sollte aber nicht Hauptgrund für die Performanceproblematik sein.
