Geschwindigkeitsproblem: großes array an trigger teilen und sortieren

Ja, die Methode mit dem Build Array.

Die lokale Variable könntest Du durch ein Shift-Register ersetzen. Aber die Performance die Du damit gewinnst ist sicherlich klein gegenüber dem, was Du durch das Überspringen der Berechnung sparst. Also nicht relevant für Dein Problem.

Kannst Du eventuell die Menge der erfassten Daten reduzieren (kleinere Samplerate?)

Kannst Du eventuell die Datenerfassung so triggern, dass Du Dir das umsortieren der Messdaten sparst?

Anzeige

Die Datenerfassung kann ich nicht so beeinflussen, dass das sortieren überflüssig wird... die Samplerate reduzieren wäre meine Notlösung

Werden die gesamten Daten auch in einer Datei abgelegt? Liegt hier vielleicht die Engstelle?

Wie oft werden denn Deine 6553600 erfasst, sprich wie oft wird Deine Datenerfassung getriggert?

Besteht die Möglichkeit, nur bei jedem zweiten Trigger-Ereignis zu erfassen, oder ist ein kontinuierlicher Datenstrom in 6553600er Blöcken zu erfassen?

Nach 13 Beiträgen ist es langsam Zeit, daß mal einer den ultimativ überzeugenden Tipp gibt, und dieser ist:
Für das Sortieren die Funktion "1D Array rotieren" verwenden.
OK, das Programmierer-Gefühl sagt, daß so eine Rotation im Array eine zeitraubende Angelegenheit ist. Man sollte sich aber von solchen Vorurteilen nicht leiten lassen, sondern einfach mal die Messergebnisse zur Kenntnis nehmen.
Hier im Beispiel dauert die Rotation eines 6000000-Array gerade mal 3µs:

   

Bei der Rotation hast Du aber die "falscher" Datenpunkte am Ende des umsortierten Arrays. Also die früher erfassten Messwerte werden bei der Rotation hinter die später erfassten Messwerte geschoben. Sie gehören in dieser Abfolge nicht zusammen; sind also physikalisch nicht mehr richtig. Messtechnisch kann es anderseits sein, dass der Unterschied nicht relevant ist, weil sich der Triggerzeitpunkt vernachlässigbar verschiebt und die Signale sehr ähnlich sind, so dass man die Rotation einsetzen könnte.

Also erstmal Danke an unicorn und Lucki fürs Gedanken machen!

Ihr habt auch beide Recht. An das "sortieren" durch rotieren habe ich noch nicht gedacht und eigentlich wollte ich die Werte auch physikalisch richtig sortieren. Trotzdem wäre es vielleicht eine Notlösung, die man ausprobieren könnte. Also Danke für diesen Hinweis!

Der Datenstrom soll kontinuierlich sein.
Das speichern der Daten ist auf jeden Fall eine Engstelle (auch wenn hier noch etwas gerechnet wurde und die Datenmenge dann nicht mehr so groß ist). Gespeichert wird aber nur optional und dann für begrenzte Zeit, so dass die Queues das abfangen. D.h. das ist nicht die Engstelle die jetzt allgemein Probleme macht.

Anzeige

' schrieb:Bei der Rotation hast Du aber die "falscher" Datenpunkte am Ende des umsortierten Arrays.

Ich habe mich an die Beispiele in #6 von tinger gehalten. Schrotti hat dazu in #7 zu den Beispielen passend die Lösung präsentiert, von der tinger aber aber sagt, so sei das nicht gewollt. Und statt das Ergebnis von Schrotti zu korrigieren, was das Einfachste gewesen wäre und definitiv Klarheit gebracht hätte, wird irgendwas drum herum erklärt, was ich nicht verstehe. Also wenn es so weiter geht, dann wird der Thread noch lang. Ich liebe solche Threads, wo sich der Frager mit Informationen immer so bedeckt wie möglich hält - angefangen beim fehlenden VI.^_^

' schrieb:Bei der Rotation hast Du aber die "falscher" Datenpunkte am Ende des umsortierten Arrays.

Ich habe mich an die Beispiele in #6 von tinger gehalten. Schrotti hat dazu in #7 zu den Beispielen passend die Lösung präsentiert, von der tinger aber aber sagt, so sei das nicht gewollt. Und statt das Ergebnis von Schrotti zu korrigieren, was das Einfachste gewesen wäre und definitiv Klarheit gebracht hätte, wird irgendwas drum herum erklärt, was ich nicht verstehe. Also wenn es so weiter geht, dann wird der Thread noch lang. Ich liebe solche Threads, wo sich der Frager mit Informationen immer so bedeckt wie möglich hält - angefangen beim fehlenden VI.^_^

Ja, da habe ich dich wirklich falsch verstanden. Du kannst eigentlich nur probieren und probieren. Am besten ist immer, verschiedene Möglichkeiten in eigenen VIs umzusetzen und dort direkt mit Dummy-Daten die Performance ermitteln. Bevor ich aber irgendwas mit allen Mitteln versuch zu programmieren, da überleg ich mir schon, obs nicht ein besseres Konzept gäbe.

' schrieb:Ja, da habe ich dich wirklich falsch verstanden.

Wieso falsch verstanden? Du hast die Beispieldaten mit Beispiel-Ergebnisse für bare Münze genommen, ewas Anderes konntest Du doch gar nicht tun. Ein ganz andere Frage, die aber damit nichts zu tun hat, ist, ob deine Löung die gewünschte Perfomance bringt.
Es gibt ja bei diesen Daten mit dem Trigger irgendwo in der Mitte nur 2 Möglichkeiten:
Enweder: Die Daten sind so angeordnet wie sie aufgenommen wurden. Dann sind sie bereits zeitlich richtig sortiert und jedes umsortieren zerstört die zeitlich monotone Reihenfolge.
Oder: Das Datenarray ist ein Rinpuffer. Unmittelbar nach dem Trigger (rechts davon, höherer Index) ) ist der älteste Wert, der vor dem Triger befindlicher Wert ist der neueste. Dann kann man das Array durch innere Rotation in die zeitlich monotone Reihenfolge bringen. Davon war ich ausgegangen.