' schrieb:Kann ich auch von folgendem ausgehen: Daten, die in einer Klasse liegen - ob als private oder public - werden nicht mehr (so oft) kopiert?
Nein, leider nicht (ich bin mir gerade zwar nicht 100%ig sicher). In diesem Fall ist das Klassenobjekt eben doch nur ein Cluster, der von VI (Methode) zu VI (Methode) weitergereicht wird.
' schrieb:Wenn ich also ein größerer 2D-Array habe, das bearbeitet werden muss, dann wird das ja mit normalem DF ständig (naja sagen wir sehr oft) kopiert. Was viel Arbeit macht. Ich könnte mir durchaus vorstellen, dass, liege dieses Array als private in einer Instanz, erheblich Kopierarbeit gespart werden könnte.
Die Zahl war 3. Die Daten werden dreifach kopiert, wenn Sie an ein SubVI übergeben werden und wieder zurückgegeben werden.
Sie müssen auf dem Frontpanel angezeigt werden, dann wird mit ihnen gearbeitet und dann ist da noch das Anzeigeelement mit dem das Ergebnis zurückgegeben wird. Das klingt nach Verschwendung. Dafür kann ich ein SubVI zum Testen immer wieder starten, nachdem es einmal aufgerufen wurde, da auf dem Frontpanel die ganzen Startdaten gespeichert sind.
Vielleicht hilft hier die "In Place Element Structure". Das müsste ich erst einmal nachlesen und probieren. Den Speicherverbrauch der VIs kann man sich mit dem Menüpunkt Tools > Profile > Performance and Memory... anzeigen lassen. Und Tools > Profile > Show Buffer Allocations... zeigt an, an welcher Stelle Kopien der Daten erstellt werden.
Aber auch mit einem FPV bekomme ich meine Daten aus meinem Beispiel nicht auf einmal hinein, weil LV eben wieder mehrere Kopien anlegt. Ich kann also meine Bilder nur einzeln nacheinander hineinschreiben.
Warum benutze ich nun nicht immer ein FPV anstelle von einer Klasse. Damit die Daten abgelegt werden können, wird ein Anschluss für das Bild zum Schreiben und ein Anschluss für das Bild zum Lesen benötigt. Außerdem muss ich angeben welche Nummer das Bild hat, das ich lesen will, bzw. an welcher Position das Bild eingefügt worden. Damit sind zwei weitere Anschlüsse verbraucht. Dann gibt es noch den Error-Cluster rein und raus sowie wie das Enum mit dem ich die Funktionalität wähle. Jetzt will ich meine Bilddaten noch in eine Datei schreiben und brauche einen Pfad Eingang. Sind zusammen schon 8 Anschlüsse. 28 hat man maximal zur Vewrfügung. Damit wird klar, dass man FPV nicht für recht komplexe "Klassen" einsetzen kann, obwohl es die Grundanforderung der Objektorientierung "Kapselung der Daten" erfüllt.
Für mein angeführtes Beispiel habe ich LVOOP und FPV kombiniert. Für das Hauptprogramm, welches im wesentlichen ein GUI bildet habe ich ein FPV, das eine Klasse enthält, damit ich in der Hauptschleife nicht meine Klasse durch alle Fälle der Ereignisstruktur hindurchführen muss. Das automatische Verbinden gibt es schließlich erst seit
, während die Anfänge des Programms weiter zurückreichen. Eigentlich reicht hier auch eine lokale Variable. Das FPV ist mehr historisch. In der Klasse selbst habe ich aber auch nicht die eigentlichen Bilddaten untergebracht, sondern nur eine Vielzahl von Funktionen vereinigt, die die Bilddaten in einem FPV organisieren und bearbeiten.
Es gibt also nicht die dogmatische Lösung. Vielmehr muss die günstigste Lösung für die jeweilige Aufgabe herausgesucht werden z. B. im Rahmen einer Diskussion hier im Forum.
