While schleife - bedingte Ausgabe

Hallo,

es gibt ja jetzt die Möglichkeit der bedingten Ausgabe aus einer While schleife (also: Autoindexing in ein Array und dabei nur wenn Bedingung erfüllt reinschreiben). Da mein letzter Wert in der Schleife müll ist wollt ich den da gleich mit rauswerfen (statt hinterher) und also den Bedingungsanschluss mit dem Schleifenende verdrahtet. Das sollte ja nicht viel machen - dachte ich.

Allerdings: Plötzlich war die Laufzeit statt 7-8s bei 24-25s (natürlich bei gleichen Eingabedaten).

Kann das schlecht hochladen da das Teil von nem LVOO Projekt ist (und ich damit deutlich mehr als das eigentliche VI hochladen müsste damit das auch funzt - das erspar ich euch und uns). Hier der betreffende Code abschnitt (aussen drumrum ist nur links die zwei inputcontrols und rechts die zwei outputs):

Ohne bedingtes Einfügen:
   

Mit bedingtem Einfügen:
   

Der Code unterscheidet sich ausschließlich an dieser einen Stelle. Verstehe diese dramatischen Unterschiede nicht bei der Laufzeit - kann mich da jemand aufklären? Sollte ja eigentlich bis auf eine If Abfrage in jedem Schleifendurchlauf mehr das gleiche machen (unter der Haube).

Gruß Kiesch

P.S: Achja, der code rechts der Schleife wirft das letzte Tabellenfeld raus (hab das Problem damit schon umgangen und das ist natürlich deutlich effizienter). Die Variante mit bedingtem Einfügen hab ich dann daraus gebastelt zur Veranschaulichung - gibt also ein leicht anderes Ergebnis als die Variante ohne bedingtes Einfügen.

Gelesen wird eine Excell tabelle mit glaube ~4600 zeilen - daher die lange Laufzeit.

P.P.S: Achja, sollte ich die Referenzen (die in der Schleife geholt werden) lieber gleich in der Schleife schließen oder ist das sinnvoller die so wie aktuell gelöst alle ausserhalb der Schleife zu schließen?

Bedingtes Concatenate ist letztendlich eine Case-Struktur mit Build Array drin. Beim reinen Concatenate Terminal ist es dann ohne Case-Struktur. Einen Performanceeinfluss hab ich schon erwartet aber einen so extremen dann doch nicht. Müsste man an einem Minimalbeispiel mal auseinandernehmen.

Minimalbeispiel angehängt. Laufzeit bei mir für 1000 Durchläufe: Bedingtes Indizieren ~ 300-330ms (mit wiederholt ausführen, nach anfänglich etwa 30% höherer Laufzeit), Indizieren 9ms (am Anfang meine ich 20-30 im ersten / zweiten Durchlauf).

Was mir aufgefallen ist, ist das für 10k Durchläufe die Ausführungszeit des Bedingten Indizierens auf 20s hochgeschossen ist (eine Größenordnung mehr Durchläufe macht also 2 Größenordnungen mehr Ausführungszeit).

Gruß Kiesch

P.S: Ich weis das das nicht wirklich nen praktisches Beispiel ist an dem man das verwenden würde (weil für nur letzten Wert wegschmeißen gibts einfachere Methoden), aber die Laufzeitunterschiede sind trotzdem dramatisch.

Achja - habe bewusst While Schleifen und fürs Stoppen nicht den Index genommen, da ich nahe an meinem Ursprungsprogram bleiben wollte und verhindern wollte das der Compiler da was wegoptimiert.

Das "bedingte Indizieren" ist gar kein indizieren, sondern, wie Holy schon sagte, ein Anhängen in einer Case-Struktur, also genau das, was man vorher ohne dieses neue Feature gemacht hätte. NI weist irgendwo selbst darauf hin, dass es sich hier nur um Kosmetik handelt. Beim Herunterspeichern auf eine niedrigere Version wird genau dieses Anhängen in der Case-Struktur gemacht.
Man muss also, um real zu bleiben, genau diese beiden Fälle vergleichen. Habe das gemacht. Das bedingte Indizieren ist immer noch langsamer, aber der Unterschied es ist nicht mehr so krass: Werte für 40000 Durchläufe: bedingt 4929 ms, mit Anhängen 4102 ms.
Aber natürlich weiß hier jeder, dass man beides bei so großen Array eigentlich nicht macht. Die gute Lösung ist: genügend großes Array initialisieren, die Initwerte durch die richtigen Werte ersetzen, den nicht benutzen Rest abschneiden. Ergebnis mit dieser Methode: 2 ms, also 2000 mal schneller !!.
Anmerkung für die, die die Version 12 nicht haben: Beim Herunterkonvertieren auf V11 wird das gemacht, was ich oben erwähnte, d.h die ersten beiden Testprogs sind dann praktisch identisch, Vergleich dann nicht mehr ergiebig.

Wenn die Performance egal ist kann man es gut einsetzen und spart einiges an Programmierzeit. Die Übersichtlichkeit nimmt auch sehr stark zu.

@Lucki: Du scheinst jetzt auch LabVIEW 2012 zu haben, daher bitte .

Gruß Markus

(10.07.2013 19:04 )Lucki schrieb:  Anmerkung für die, die die Version 12 nicht haben: Beim Herunterkonvertieren auf V11 wird das gemacht, was ich oben erwähnte, d.h die ersten beiden Testprogs sind dann praktisch identisch, Vergleich dann nicht mehr ergiebig.

Anzeige

Grade kurz getestet - tritt auch bei For Schleifen auf (obwohl man das vermutlich einfach deutlich performanter Lösen könnte, da man schon weis wie groß das Array maximal werden kann.

Was lernen wir also draus:

1. Die Methode wird um so schneller je mehr man Filtert (weil bei gefilterten Elementen das Build Array entfällt).
2. Ob For oder While Schleife macht keinen Unterschied.
3. NI hat also mal wieder was völlig unausgegorenes Auf den Markt geworfen was man performanter Lösen könnte wenn mans selbst macht - aber dann nur wieder für einzelne jeden Fall den man hat einzeln...


Verstehe auch nicht warum man sich nicht an der GOOP Variante orientiert hat die ist deutlich performanter:


  TestVI bedingtes Indizieren_Modifiziert.vi (Größe: 18,23 KB / Downloads: 219)


Mit der Einschränkung das GOOP eben nur in bestimmten Fällen funktioniert, da das GOOP VI ja nur ein Polymorphes ist das für ne begrenzte Zahl an Datentypen definiert ist. Vorgehen dabei ist: Filtern nach der Schleife. Braucht bei mir nur ~10-20% länger als ohne Bedingtes Indizieren - was ganz gut ist da ich im Test-VI ja den Worst Case (nichts filtern) benutze.

Kann man sowas irgendwie / irgendwo bei NI anregen den Code unter der Haube so umzubauen? Ich meine unter der Haube kann man die Methode die bei GOOP verwendet wird sicher auch global einmal definieren für beliebige Datentypen...

Gruß Kiesch

(11.07.2013 10:59 )Kiesch schrieb:  Kann man sowas irgendwie / irgendwo bei NI anregen den Code unter der Haube so umzubauen?

LabVIEW Idea Exchange!
Gruß, Jens

Wieso soll das unausgegoren sein? Du sagst doch selbst das die performanteren Lösungen alle nur für bestimmte Fälle funktionieren.
Das Äquivalent zum "bedingten Anhängen" hat schon immer seine Daseinsberechtigung gehabt und lässt sich dadurch nur schneller programmieren und es gibt mehr Überblick. Das die Performance dieser Lösung nicht optimal sein kann war nicht anders zu erwarten.

(11.07.2013 18:45 )Holy schrieb:  Wieso soll das unausgegoren sein?

Das würde ich nicht so ernst nehmen, das ist doch eher Werbung in eigener Sache. Die wichtige unterschwellige Botschaft ist doch, dass der das schreibt ein großer Experte sein muss.