INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Datei-Parser optimieren



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, 16:19 (Dieser Beitrag wurde zuletzt bearbeitet: 27.11.2008 16:19 von Lucki.)
Beitrag #11

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
Datei-Parser optimieren
' schrieb:Das Problem ist, dass ich nicht genau weiss mit wie vielen Werten ich meine Arrays vorinitialisieren soll.
Eben genau das ist kein Problem. Die Ausführungszeit leidet nicht messbar darunter, wenn Du Dich in der Abschätzung der maximalen Arraygröße um den Faktor 10 oder 100 nach oben hin geirrt hast. Der nicht verwendete Rest wird ja abgeschnitten. Daß ich im Besipiel eine For-Schleife verwendet habe, war vielleicht irreführend, ich wollte damit nur den Stop-Knopf einsparen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
27.11.2008, 17:12
Beitrag #12

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
Datei-Parser optimieren
.. Und da hier, obwohl eigentlich LV-Grundwissen, offensichtlich kein allgemeiner Konsens herrscht, daß die Funktion "Array erstellen" bei Addition von immer neuen Elementen mit der Zeit katastrophal langsam wird, mußte ich also ein Beispiel basteln, um das zu demonstrieren. (Man nehme bitte nicht Anstoß daran, daß man bei Verwendung der For-Schleife hier das mit Indexieren hätte einfacher machen können).
Daß´das die einfache Ursache für die Langsamkeit Deines VI ist, ist für mich jedenfals "klar wie Kloßbrühe"
   
Ergebnis bei Erstellung von 100 000 Elementen: fast 1000 (!) facher Geschwindigkeitsvorteil bei Elemente ersetzten statt Array mit jedem Element vergrößeren.
Gruß Ludwig
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
27.11.2008, 17:17
Beitrag #13

eg Offline
LVF-SeniorMod


Beiträge: 3.868
Registriert seit: Nov 2005

2016
2003
kA

66111
Deutschland
Datei-Parser optimieren
Na schön, wenn es so ein Riesenunterschied ist, dann lohnt es sich wirklich weiter dran zu arbeiten.

Danke

Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
27.11.2008, 19:21
Beitrag #14

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.689
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Datei-Parser optimieren
' schrieb:daß die Funktion "Array erstellen" bei Addition von immer neuen Elementen mit der Zeit katastrophal langsam wird,
... was daran liegt, dass pro Ausführung des Additions-Elementes das komplette Array neu allociert wird - sprich es wird komplett umkopiert.

Man muss ja nicht von vorne herein das Array so groß machen wie nötig. Wenn es so groß ist wie 1000 Datensätze, reicht das auch. Sind die tausend voll, wird es um weitere 1000 erweitert. Um jeweils 1000 zu erweiteren geht auf jeden Fall erheblich schneller als 1000 mal einen Einzelsatz zu erweitern. Am Ende wird der Rest wie gehabt abgeschnitten.

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
27.11.2008, 20:16 (Dieser Beitrag wurde zuletzt bearbeitet: 27.11.2008 20:23 von eg.)
Beitrag #15

eg Offline
LVF-SeniorMod


Beiträge: 3.868
Registriert seit: Nov 2005

2016
2003
kA

66111
Deutschland
Datei-Parser optimieren
' schrieb:... was daran liegt, dass pro Ausführung des Additions-Elementes das komplette Array neu allociert wird - sprich es wird komplett umkopiert.

Man muss ja nicht von vorne herein das Array so groß machen wie nötig. Wenn es so groß ist wie 1000 Datensätze, reicht das auch. Sind die tausend voll, wird es um weitere 1000 erweitert. Um jeweils 1000 zu erweiteren geht auf jeden Fall erheblich schneller als 1000 mal einen Einzelsatz zu erweitern. Am Ende wird der Rest wie gehabt abgeschnitten.

Das halte ich wirklich für eine tolle Idee, auch in Hinsicht, dass nicht das komplette vorinitialisierte Array über den Schieberegister bei jeder Iteration von Anfang an geschaufelt wird.

So mache ich das.

P.S. eine Frage interessiert mich dennoch. Wenn ich das VI Array Size verwende, wird dabei eine Kopie des Arrays erzeugt oder nicht? Aber ich glaube ich kriege es selbst raus.

Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
27.11.2008, 21:24
Beitrag #16

Falk Offline
ja, das bin ich...
***


Beiträge: 343
Registriert seit: Jan 2006

8.0 :: 201x ::202x
2006
DE_EN


Deutschland
Datei-Parser optimieren
' schrieb:... was daran liegt, dass pro Ausführung des Additions-Elementes das komplette Array neu allociert wird - sprich es wird komplett umkopiert.

Man muss ja nicht von vorne herein das Array so groß machen wie nötig. Wenn es so groß ist wie 1000 Datensätze, reicht das auch. Sind die tausend voll, wird es um weitere 1000 erweitert. Um jeweils 1000 zu erweiteren geht auf jeden Fall erheblich schneller als 1000 mal einen Einzelsatz zu erweitern. Am Ende wird der Rest wie gehabt abgeschnitten.

Hehe, als ich vor kurzem meine Verwunderung gegenüber dieser Tatsache zum Ausdruck gebracht habe, bekam ich nur als Antwort: Wer C programmiert hat wüßte das.Big Grin

Schöne Grüße
Falk

Currently: zzzZZZZZZZZ
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
27.11.2008, 22:22
Beitrag #17

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.689
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Datei-Parser optimieren
' schrieb:dass nicht das komplette vorinitialisierte Array über den Schieberegister bei jeder Iteration von Anfang an geschaufelt wird.
Was in Schieberegistern liegt, wird beim Abarbeiten z.B. einer Statemachine in der Whileschleife nicht umkopiert. Solange es irgend geht, wird mit dem Speicher des Schieberegister gearbeitet. Guckst du Pufferbelegung.

Einen Test hab ich mal gemacht: Sampeln Canbus. 5 Prüflinge, 100 Dbl-Variablen pro Sample, 180 Sekunden Samplezeit, 10ms Sampleraster. Macht ein 3D-Array der Größe 5*100*(180*100)*8 = 72MB. Das Array wird zu Beginn erstellt, die Daten werden im Array ersetzt. Prozessorauslastung 6% bei 50ms Arbeitsraster des VIs. Da wird nix kopiert.

Das VI "Arraylänge holen" ist wohl eines der allereinfachsten. Da wird im Falle eines 1D-Arrays lediglich ein I32 kopiert. Am Verzweigungspunkt, hab ich mir überlegt, ist es nicht notwendig, eine Kopie zu erstellen. Alleine am Beginn einer Datenflusses ist es notwendig Speicher zu allizieren.

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
28.11.2008, 08:39
Beitrag #18

RoLe Offline
LVF-Guru
*****


Beiträge: 1.236
Registriert seit: Jul 2007

-
1997
en

0
Schweiz
Datei-Parser optimieren
' schrieb:Man muss ja nicht von vorne herein das Array so groß machen wie nötig. Wenn es so groß ist wie 1000 Datensätze, reicht das auch. Sind die tausend voll, wird es um weitere 1000 erweitert. Um jeweils 1000 zu erweiteren geht auf jeden Fall erheblich schneller als 1000 mal einen Einzelsatz zu erweitern. Am Ende wird der Rest wie gehabt abgeschnitten.
' schrieb:So mache ich das.
Würde ich nicht so machen, das ist eher eine Speicherverwendungsoptimierung und bremmst deine Schlaufe aus.
Du wolltest es ja möglichst schnell haben.

' schrieb:.... als Antwort: Wer C programmiert hat wüßte das.Big Grin

Auch wer C (oder Delphi) programmiert kann den falschen Ansatz wählen Wink

.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
28.11.2008, 08:42
Beitrag #19

RoLe Offline
LVF-Guru
*****


Beiträge: 1.236
Registriert seit: Jul 2007

-
1997
en

0
Schweiz
Datei-Parser optimieren
' schrieb:Ergebnis bei Erstellung von 100 000 Elementen: fast 1000 (!) facher Geschwindigkeitsvorteil bei Elemente ersetzten statt Array
Naja, soviel wird es nicht sein, da noch das Datei lesen als bremse in der Schlaufe liest.
Wenn eg genug Speicher hat, würde ich die Datei vorher komplett auslesen und das Parsen (die Schlaufe) wird noch schneller ohne das Datei lesen.

.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
28.11.2008, 09:27 (Dieser Beitrag wurde zuletzt bearbeitet: 28.11.2008 09:30 von Lucki.)
Beitrag #20

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
Datei-Parser optimieren
' schrieb:Das halte ich wirklich für eine tolle Idee, auch in Hinsicht, dass nicht das komplette vorinitialisierte Array über den Schieberegister bei jeder Iteration von Anfang an geschaufelt wird.
Wenn man den Thread mit nunmehr 19 Beiträgen verfolgt, dann erhält man den Eindruck, die Umstellung Deines Programm hin zum Ersetzen von Elementen sei ein ungeheures Projekt, das erst mal von allen Seiten diskutiert werden muß, bevor man es angeht. In Wirklichkeit wäre doch diese Umstellung in 15 min erledigt, was hindert Dich eigentlich daran, statt Worte mal eine Tat folgen zu lassen? Wenn es nicht den erwarteten Erfolg bringt, dann kann man immer noch den weitergehenden Vorschlägen nachgehen. Ich selbst glaube allerdings nicht, daß das noch etwas bringt. Z.B Schieberegister: Ja, optisch im Blockbild sieht es natürlich so aus, daß bei einem Schieberegister immer alles nach vorn - nach hinten -nach vorn ... geschaufelt wird. Ich bezweifle nur, daß das in der internen programmtechnischen Realisierung überhaupt so ist, dann wenn es wirklich so wäre, dann müßten Schieberegister um ein Vielfaches langsamer sein als sie es in Wirklichkeit sind. Die Geschwindigkeit von Schieberegistern ist doch bei jedem Programm wirklich das Allerletzte, um was man sich Sorgen machen muß.
Gern nehme ich Dein Angebot wahr, daß Du das Programm mal postest. Ich stelle es dann in der vorgeschlagenen Weise um, das geht ja ganz schnell.
Gruß Ludwig
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Gehe zu: