LabVIEWForum.de

Danke für den weiteren Test... anbei nur ein kleiner Fix für den Speedtest... sonst läuft der Speicher so schnell voll
[attachment=32691] LV2010

Und wer genau nachforscht stellt fest, dass alles nur daran liegt, dass in dem einen Falle "Daten samt Pointer" kopiert werden und im anderen nicht. Schreib mal in den String was anständiges rein und miss dann noch mal die Zeit.

Ich versteh's nicht... mit befülltem String komme ich auf:
[attachment=32697]

[attachment=32696]lv2010

Poste doch mal bitte deine Version.

Spielerei:

Ist der String im Cluster leer, dauer die ganze Sache mit der lokalen Variablen 10ms. Steht ein einziges Zeichen im String, dauert die Sache plötzlich 20ms. Genau so lange dauern auch 4 Zeichen im String. 32 Zeichen dauern ungefähr 25ms.

Wo kommt der Sprung von 10ms auf 20ms her?

Ich tippe auf folgendes:
Beim Auslesen der Lokalen Variablen wird für das komplette Array neuer Speicher angefordert. In diesen Speicher wird das Array kopiert. Beachte: Wenn der String leer ist, steht im Cluster für den String ein Null-Pointer. Ob LV das genau so macht, weis ich natürlich nicht. Es ist aber extrem sinnvoll: Null-Pointer bedürfen nämlich keiner weiteren Operation.
Steht im String ein einzelnes Zeichen, so muss für den String, der jetzt nicht mehr leer ist, zusätzlich ein Speicher angefordert werden (das haben Strings so an sich). In diesen Speicher wird dann der Stringinhalt (also die Daten) kopiert. Und dieses Speicher-Anfordern alleine dauert die 10ms. Und da ist noch nix mit Daten kopieren dabei.
Das kopieren der 32 Zeichen summiert sich dann halt auf 5 zusätzliche Millisekunden.

Was will ich jetzt damit sagen? Zwei Sachen:

Je komplizierter der Cluster um so aufwändiger die Speicherbereitstellung und das kopieren.

Viel wichtiger hier ist aber folgendes:
Bei Verwendung einer lokalen Variablen müssen die Daten kopiert werden. Einen Pointer auf die Daten in der Lokalen Variablen zu verwenden geht nicht. Es besteht nämlich die Möglichkeit, dass ein paralleler Prozess auch auf die Daten der Lokalen Variablen zugreifen will. Ein zweifacher Pointer-Zugriff aber ist tödlich.
Verwendet man eine Queue, sieht die Sache ganz anders aus: Beim Auslesen der Queue muss man keine Daten kopieren! Da kann man den Bereich nehmen, der bereits vorhanden ist: Es gibt nichts in irgendwelchen parallelen Prozessen, das auch auf die Daten in der Queue zugreifen kann: einmal ausgelesen, sind die Daten nicht mehr "da". Warum also kopieren?


Hinweis:
Ob LV das auch genau so macht, wie ich es mir vorstelle, weis ich nicht. Da gibt es andere. Es spricht nur sehr, sehr viel dafür.

Mein Untersuchungen lassen vermuten, daß der gesamte Zeitverbrauch einzig und allein durch das Lesen und Beschreiben der Anzeigen zustandekommt.
Queue: Kein Lesen und Schreiben von Anzeigen --> kein Zeitverbrauch
Globale Variable: Lesen und Beschreiben der Anzeige im Global-VI
Lokale Variable: Lesen und Beschreiben der Anzeige im Main-VI

Werden keine Anzeigen gelesen/geschrieben, wird auch keine nennenswerte Zeit gebraucht. Die Arrayoperationen, obwohl hier sicherlich Kopien angelegt werden müssen, sind es jedenfalls nicht, die Zeit verbrauchen.
[attachment=32706]
[attachment=32707]

(09.03.2011 18:12 )IchSelbst schrieb: [ -> ]Ich tippe auf folgendes:
Beim Auslesen der Lokalen Variablen wird für das komplette Array neuer Speicher angefordert. In diesen Speicher wird das Array kopiert. Beachte: Wenn der String leer ist, steht im Cluster für den String ein Null-Pointer. Ob LV das genau so macht, weis ich natürlich nicht. Es ist aber extrem sinnvoll: Null-Pointer bedürfen nämlich keiner weiteren Operation.
Steht im String ein einzelnes Zeichen, so muss für den String, der jetzt nicht mehr leer ist, zusätzlich ein Speicher angefordert werden (das haben Strings so an sich). In diesen Speicher wird dann der Stringinhalt (also die Daten) kopiert. Und dieses Speicher-Anfordern alleine dauert die 10ms. Und da ist noch nix mit Daten kopieren dabei.

So abwegig scheint dies auch nicht zu sein:
Schöne Grüße
Falk

(09.03.2011 19:16 )Lucki schrieb: [ -> ]daß der gesamte Zeitverbrauch einzig und allein durch das Lesen und Beschreiben der Anzeigen zustandekommt.

Guckst du neues Muster. Da ist der Case mit der Queue doch tatsächlich ein ganz klein, klein bisschen langsamer: Ohne Anzeigeelement, nur kopieren.

Ja, und natürlich kommt die Zeit vom "Auslesen des Anzeigeelementes". Hier wird kopiert. Die Array-Operationen selbst sind natürlich schnell. Die selbst arbeiten mit einem Pointer, der in den eingehenden Datenfluss zeigt. Kopiert wird immer nur am Knoten (und wenn's ein fiktiver ist wie beim Lesen des Anzeigeelementes) bzw. an der Verzweigung im Datenfluss.

(09.03.2011 11:50 )IchSelbst schrieb: [ -> ]Und wer genau nachforscht stellt fest, dass alles nur daran liegt, dass in dem einen Falle "Daten samt Pointer" kopiert werden und im anderen nicht. Schreib mal in den String was anständiges rein und miss dann noch mal die Zeit.

Puh... und ich dachte schon, du hast einen Fall gefunden in dem mehr Daten kopieren schneller geht als weniger.

Variablen _müssen_ die Daten kopieren.
Queues _können_ Daten kopieren, bei richtiger Verwendung tun sie es aber nicht (ggf. selbst wenn eine Buffer allocation angezeigt wird!).