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!
27.11.2008, 12:33 (Dieser Beitrag wurde zuletzt bearbeitet: 27.11.2008 12:33 von eg.)
Habe mal einen einfachen Parser gemacht. Nun dauert das Einlesen und Parsen viel zu lange. Was kann man hier noch optimieren, damit es schneller geht?
Ich denke das VI Build Array könnte man ersetzen und was wichtig ist, dass die Riesenarrays nicht die ganze Zeit durch die Schieberegister hin und her geschaufelt werden
' schrieb:Ich denke das VI Build Array könnte man ersetzen und was wichtig ist, dass die Riesenarrays nicht die ganze Zeit durch die Schieberegister hin und her geschaufelt werden
Wenn die grösse des Array in etwa bekannt ist, Array initialisieren und in der Schlaufe nur noch ersetzen.
Ob die Datenmenge in dem SR das "Parsen" verlängern, bin ich mir jetzt nicht sicher.
Ev. brinngt es was, den Cluster durch ein entsprechendes Array zu ersetzen.
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Ja, ein Beispiele zu machen dauert eben immer länger als ein schnelle Antwort zu geben...
Bei dieser Dateigröße wird es garantiert größenordnungsmäßige Unterschiede in der Ausführungszeit geben, wenn man den Array vorinitialisiert, die Elemente erstetzt und den nicht benutzten Rest abschneidet. Wie Role schon sagte.
Ein Shift-Register ist doch das schnellste, was es überhaupt gibt, am Herumschieben in diesem liegt es bestimmt nicht, wenn es zu langsam ist
Also im Prinzip so: Parser.vi (Größe: 7,85 KB / Downloads: 243)
Wichtiger Hinweis: Die erreichte Verbesserung in der Ausfpührunungszeit ist meldepflichtig!
Das Problem ist, dass ich nicht genau weiss mit wie vielen Werten ich meine Arrays vorinitialisieren soll. Evtl. kann man es aus der Dateigröße ausrechnen, aber einfach ist es nicht, da ich unterschiedliche Pakete mit unterschiedlichen Frequenzen (also zufälliges Vorkommen) im File habe. Wenn die Pakete von einem Typ wären, dann ginge es einfach.
Falls Interesse da ist, kann ich den aktuell benutzten Parser und die Datei hier hochladen. In dem VI werden dann noch die Arrays miteinander (anhand des Paketcounters) synchronisiert und noch drei FFTs gemacht. Insgesammt nimmt es eine Menge Zeit, was ziemlich unangenehm ist.
Und ja, soll noch dazu sagen, dass ich es zuerst anders gemacht habe. Ich habe die gesamte Datei eingelesen und dann mit Unflatten From String geparst. Den Rest nach dem Unflatten habe ich in einem weiteren Schieberegister gespeichert. Der Rest war also mit jeder Iteration immer kleiner.
Nun ist es noch 100X langsamer gelaufen. Der Parser ist also jetzt schon ein Mal von mir optimiert worden.
Übrigens, die Synchronisierung der Pakete könnte evtl. auch optimiert werden
So etwas ähnliches habe ich vor nicht allzu langer Zeit auch gemacht. Bei handelt es sich aktuell aber im Dateigrößen um die 1-5 GB. Da brauchte ich ca. 8 Minuten um die Datei einmal zu durchlaufen.
Hinsichtlich deines letzten Cases. Du liest dort deine Daten aus dem File und packst sie an den Array. Bei einer Dateigröße von 18 MB ist das sicherlich auch kein Problem, bei mehr wird der Arbeitsspeicher recht schnell stark belastet.
Ist es bei dir notwendig, dass du alle Daten auf einmal benötigst?
Bei mir ist es so, dass in den Dateien Spektren stecken. Dass können schon mal mehr als 100000 sein, darum auch die wahnsinnige Dateigröße nach einer Messung. Da man später nicht alle Spektren auf einmal benötigt, habe ich das erstmalige Einlesen der Datei so gestaltet, dass ich mir nicht alle Spektren aus der Datei heraushole, sondern nur die Angaben wo die Spektren in der Datei stehen und wieviele Bytes dazu gehören. Quasi eine Art Pointer auf die einzelnen Datensegmente. Im weiteren Verlauf kann ich mir dann unter Angabe dieser beiden Parameter jedes Spektren aus der Datei herausholen. Den Vorteil sehe ich daran, dass man den Arbeitsspeicher weniger belastet und man trotzdem jedes Datenpacket eindeutig referenzieren kann. Aber das hängt natürlich davon ab, was im Anschluss mit den Daten erfolgen soll.
Hallo Falk! An diese Idee habe ich auch schon gedacht.
Es ist so, dass ich im Normalbetrieb des Programms ein Mal pro Stunde eine neue Datei anlege (erstens damit beim Absturz nur die letzte Stunde der Daten verloren geht und zweitens damit die Dateien nicht zu groß werden). Auswählen des Bereichs zum Parsen kann ich mir nicht so gut vorstellen, denn die Auswahlkriterien in der Datei versteckt sind (etwa Zeitstempeln oder Counters) und deshalb die Datei zuerst zum Vorschau geparst werden sollte. Klar, man könnte z.B. nur ein Paket vorne und ein Paket hinten parsen um die Counters auszulesen. Aber da ich nicht mehr so viel Zeit habe und das Projekt demnächst abgeben soll, will ich es mir nicht antun.
