Besserer Ersatz für Array

[OOP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
Ich habe einen FB erstellt, welchem man über eine Add Methode werte hinzufügen kann. (Werden in einem array abgelegt).
Nun können diese Werte aufgrund bestimmter Umstände auch wieder gelöscht (auf 0 gesetzt werden)
Wenn ein Wert hinzugefügt wird, soll geprüft werden ob es diesen schon gibt. Ich durchlaufe dann dass Array, frage auf gleich dem Wert ab und wenn es ihn nicht gibt füge ich ihn bei einem Element mit Wert 0 ein.
Wenn man nun 100 werte in einem Zyklus hinzufügen möchte, dann muss man allerdings 100 mal das Array durchlaufen.

Hat jemand eine Idee wie man das geschickter aufbauen kann?

 

[PN/DP]

Müssen denn unbedingt alle 100 Werte im selben Zyklus zugefügt werden? Man könnte das auf mehrere Zyklen aufteilen, z.B. max 20 je Zyklus. Das wäre auch besser im Sinne von möglichst gleichlangen Zyklen.
Wie groß (Bytes) ist ein Eintrag?

Anstatt einfaches Array könnte man eine sortierte verkettete Liste nehmen, oder zusätzlich zum Datensatz-Array ein sortiertes Index-Array verwenden, was sortiert die Indizes auf das Datensatz-Array enthält. Wenn Einträge sortiert sind, dann kann man sehr effizient durch binäre Suche einen Eintrag finden oder feststellen daß es den Eintrag nicht gibt: z.B. bei 100 Einträgen brauchen nur 7 Einträge gelesen werden.

Harald

 

[OOP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Anzahl der hinzugefügten Daten sollte nicht begrenzt werden (anwendungsbedingt)
Datengrösse beläuft sich aktuell auf ca. 16 Byte.
Mit dem sortierten indexierst Dir Idee finde ich schon mal nicht schlecht, aber dieses muss ich doch auch nach jedem Adden sortieren, oder? Kommt das dann nicht je nach sortieralgorythmus aufs gleiche raus?

 

[PN/DP]

Bei jedem Hinzufügen müsste neu sortiert werden bzw. der Zeiger (Index) auf das neu hinzukommende Element gleich an der richtigen Stelle eingefügt werden:
- über das Index-Array binär suchen ob es den Eintrag schon gibt
- im Datensatz-Array irgendeinen nicht belegten Eintrag suchen und den neuen Datensatz dahin speichern (die freien Einträge können auch ans Ende des Index-Arrays sortiert werden, dann findet man die schneller)
- im sortierten Index-Array die Einfügestelle suchen (bzw. ist ja schon gefunden vom ersten Schritt), die nachfolgenden Einträge (Indizes) um 1 Eintrag verschieben und an der freigewordenen Stelle den Index des im Datensatz-Array eingefügten neuen Datensatzes eintragen

Ich weiß nicht was für eine SPS-CPU Du hast und wie schnell die ist, doch das Suchen und Umspeichern von 100 x 16 Byte sollte keine große Belastung sein. Du müsstest aber mindestens einmal testen um wieviel sich die Zykluszeit bzw. Programmausführungszeit erhöht im worst case beim Hinzufügen der technisch maximal möglichen Anzahl neuer Datensätze - nicht daß die möglicherweise Zykluszeitüberschreitung erst beim Kunde passiert. Bei SPS werden worst cases vor Anlagenstart getestet und nicht "gehofft" daß so ein Fall nicht eintritt.

Verkettete Listen und sortierte Index-Arrays bringen Geschwindigkeitsvorteile besonders bei größeren Datensätzen, weil man da bei Hinzufügen und Sortieren nur die Indizes umspeichern muß und nicht die größeren Datensätze. Ob bei kleinen Datensätzen solche aufwendigeren Verwaltungsmethoden effizienter sind müsste man vergleichen.

Harald

 

[Heinileini]

Bei SPS werden worst cases vor Anlagenstart getestet und nicht "gehofft" daß so ein Fall nicht eintritt.

Jawoll! Sehr gut! Aber Vorsicht, bitte beim Festlegen, welches der WurstKäse (worst case) ist, nicht schon die allerwurstigsten von vornherein ausschliessen, weil man hofft, dass sie sowieso nicht oder schlimmstenfalls nur alle JubelJahre mal auftreten könnten. Bei einem geschönten worst case Szenario führt auch der VorabTest zu einem geschönten Ergebnis.
Das ist so selbstverständlich, dass man es eigentlich nicht betonen müsste, aber ich habe schon zu oft erlebt, dass sich Kollegen auf solche Abenteuer eingelassen haben.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

. . . dann kann man sehr effizient durch binäre Suche einen Eintrag finden oder feststellen daß es den Eintrag nicht gibt . . .

"Oder feststellen, dass es den Eintrag nicht gibt" ist der Fall, der beim sequentiellen Suchen am längsten dauert, weil dann wirklich alle Einträge geprüft werden müssen. Je nach Anwendung kann man sehr oft den Fall haben, dass der gesuchte Eintrag noch nicht vorhanden ist und spart dann entsprechend häufig Zeit durch die binäre Suche.
Empfehlenswert ist, eine Liste bzw. Verkettung der freigewordenen SpeicherPlätze zu führen bzw. durchzuführen, so dass nicht die Zuweisung eines SpeicherPlatzes für einen neuen Eintrag in langwierige Sucherei ausartet.