Clusterarrays synchronisieren

Danke dir, es spart mir 8 Sekunden auf meinem Rechner. Die alte Version hat 20 Sekunden gebraucht und deine 12 Sekunden.

Anzeige

' schrieb:Danke dir, es spart mir 8 Sekunden auf meinem Rechner. Die alte Version hat 20 Sekunden gebraucht und deine 12 Sekunden.

Gut, aber was ich noch sagen wollte: Mein Rechner ist schon älter und nicht besonders schnell. Wenn es trotzdem bei mir schneller läuft, dann vielleicht deshalb, weil ich LV8.6 benutzt habe.

' schrieb:Danke dir, es spart mir 8 Sekunden auf meinem Rechner. Die alte Version hat 20 Sekunden gebraucht und deine 12 Sekunden.

Und warum hattes Du die Variante mit dem Einlesen der ganzen Datei auf einmal und anschließendes Auswerten eigentlich fallen gelassen? Ich habs jetzt vor dem Einschlafen mal probiert, da ist die Dauer nur noch gefühlte 2 Sekunden!
Es war auf die Schnelle und ist vielleicht noch nicht ganz fehlerfrei.


  GSM_Parse_FileWA3.vi (Größe: 37,16 KB / Downloads: 191)


  Pack_Acc.ctl (Größe: 6,22 KB / Downloads: 176)

  Pack_DMS.ctl (Größe: 6,57 KB / Downloads: 166)

Oh ja, je tiefer man selbst programmiert umso schneller ist die Ausführung des Code. Habe nun die von mir nicht beliebte State Machine aus deinem tollen Vorschlag entfernt, aber trotzdem nichts an Zeit gewonnen.
Ich glaube man kann nicht mehr viel machen (evtl. noch die In Place Struktur, aber glaube ich nicht).
Bei dir ist das Error Cluster schon mal nicht vorhanden, das spart sicherlich sehr viel Zeit, außerdem ist das automatische Unflatten From Binary mit Type Cast ersetzt, was bestimmt auch etwas CPU Takte spart.

Also vielen Dank nicht nur für den Vorschlag, sondern auch für die gemachte Erfahrung (siehe ersten Satz).

Gruß, eg

   


  GSM_Parse.zip (Größe: 2,64 MB / Downloads: 188)

Hallo zusammen

@Lucki
Klasse Verbesserung, da kann (muss) ich noch viel lernen.
Ein kleiner Fehler ist mir jedoch aufgefallen. Close File fehlt (Speicherleck) oder hab ichs übersehen?
@eg / alle
Zur allgemeinen Struktur: Mir ist als allererstes in den Sinn gekommen die Datei schon bei der Erstellung in TDMS zu ersetzten.
Das hätte den Vorteil das ich mir verschiedene Gruppen mit beliebig vielen Kanälen anlegen kann (Skalierbar).Zudem ist es ein Streaming
Format und dadurch sollten auch nach einem Stromausfall die Dateien noch intakt sein. Man kann zusätzlich Properties für Datei/Gruppe/Kanal
setzten und diese Dateien später in Excel (kommt auf die Größe an) bzw. Diadem einlesen und auswerten/verwalten.

Klar das ist nicht mal eben kurz umprogrammiert aber mich würde interessieren was Ihr von diesem Ansatz haltet?

Gruß
Ralf

Hallo eg,
ich habe noch etwas gebastelt (Grundlage GSM-Parse-File/Lucki) und eine Dual-Core Version erstellt. Ergebnis ~300ms/~20% schneller.
Nachteil: mehr Speicherbedarf siehe Anhang.

Gruß
Ralf

Anzeige

' schrieb:ich habe noch etwas gebastelt (Grundlage GSM-Parse-File/Lucki) und eine Dual-Core Version erstellt. Ergebnis ~300ms/~20% schneller.
Nachteil: mehr Speicherbedarf siehe Anhang.

Sehr interessant, leider habe ich mein LabVIEW nicht auf einer Dual-Core Maschine und kann das nicht vergleichen. Bei mir kommt in beiden Fällen ca 1.8sec heraus, wobei ich allerdings das Einlesen der Datei mit in die Zeit einbeziehe.
Der Mehrbedarf an Speicher muß überhaupt nicht sein, das liegt doch nur daran, daß Du erst die gesamte Datei einliest und dann die Datei in zwei Telíle splittest, wodurch nochmal eine Kopie der Daten entsteht.
Besser ist es, die Datei von vornherein in zwei Hälften einzulesen. Habe das unten mal versucht. (Diese lästigen Elemente mit Typdefinition habe ich ausgetauscht)

  GSM_Parse_File_Dual_Core_WA.vi (Größe: 42 KB / Downloads: 169)

' schrieb:@Lucki
Ein kleiner Fehler ist mir jedoch aufgefallen. Close File fehlt (Speicherleck) oder hab ichs übersehen?

Bis Du hier nicht ein wenig zu streng? Ist das nicht eher eine "kleine Nachlässigkeit"? Ich hatte mal eine Reklamation, allerdings war das beim Schreiben in eine Datei. Zwar hatte ich die Datei wieder geschlossen, aber erst am Ende des Programms. Die Folge war, daß Excel nicht auf die Datei zugreifen konnte, solange das LV Prog noch lief. Aber hier beim Lesen, was soll da passieren? Was meinst Du mit "Speicherleck"?

Guten Morgen,
Lucki perfekt.
Wenn ich im Taskmanager LabVIEW nur einen Kern zuweise bin ich bei ~1,7s, bei zweien ~1,2s.
Da das mit dem Speicherbedarf, wenn man es richtig macht, auch kein Problem ist ziehe ich meine Aussage "Nachteil: mehr Speicherbedarf siehe Anhang."
hiermit zurück. (Frage an die Mods. Reicht das oder muss ich editieren)

Gruß
Ralf

Hallo Lucki

Zitat: "Bis Du hier nicht ein wenig zu streng?" - Nein
Aber es ist mir beim Post an den falschen Adressaten gerutscht, du hattest ja geschrieben das noch kleine Fehler enthalten sein können.Sorry
Mit Speicherleck meine ich wenn die Applikation tagelang läuft und hunderte Dateien geöffnet (Referenz) und nicht wieder geschlossen (freigegeben) werden, dass dann halt der Speicher leckt.

Gruß
Ralf