Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[MartinP]

@asgothian sagte in Blockly Oder-Verknüpfung:

Hinterm Spoiler mein Universeller Ansatz für n zu prüfende Elemente.

Eine Frage zur Effizienz der Implementierung: Die Liste der gesetzten Datenpunkte ändert ja dynamisch ihre Größe - was für Penalties gibt es durch die dadurch verursachte Speicherverwaltung...

Wäre ggfs eine statische Liste, in der man die Zustände ablegt und nachher auf true abfragt effizienter?
Wenn man sich darauf verlassen könnte, dass immer abwechselnd von jedem Datenpunkt True oder False kommt, könnte man ggfs. auch einen einfachen Zähler nutzen...

Hereinkommende "Trues" inkrementieren, Hereinkommende "False" dekrementieren...

[Asgothian]

@martinp sagte in Gelöst: Blockly Oder-Verknüpfung:

Wäre ggfs eine statische Liste, in der man die Zustände ablegt und nachher auf true abfragt effizienter?
Wenn man sich darauf verlassen könnte, dass immer abwechselnd von jedem Datenpunkt True oder False kommt, könnte man ggfs. auch einen einfachen Zähler nutzen...
Hereinkommende "Trues" inkrementieren, Hereinkommende "False" dekrementieren...

Das mit dem einfachen Zähler setzt voraus das da nichts schief geht. So hatte ich das am Anfang, aber meine Erfahrung damit war eher durchwachsen - der hat sich eigentlich ständig verzählt, so das oft die Meldung nicht zum Zustand gepasst hat. Unglücklicherweise wird das Verzählen eigentlich immer nur in eine Richtung erkannt - Jede Anwendung hat da ihre "Vorzugsrichtung". Im aktuellen Beispiel ist der Fall "es ist alles offen" eher selten, so das ein Verzählen nach oben kaum erkannt wird, aber dazu führt das der Alarm nie zurück gesetzt wird.

Das mit der statischen Liste ist auch so eine Sache - dann hat man statisch mehr Speicher belegt nur um nicht dynamisch zu arbeiten. Man braucht entweder eine Liste von Objekten mit properties oder zwei Listen die Synchron gehalten werden müssen - incl. dem durchgehen durch die Liste um zu ermitteln wieviele denn nun "wahr" und "falsch" zeigen. Wie genau der JS Garbage-Collector arbeitet weiss ich nicht - allerdings gehe ich davon aus das der Speicherplatz beim Austragen eines Elementes nicht sofort sondern mit Verzögerung freigegeben wird. Ich denke der Ansatz bildet da einen brauchbaren Kompromiss.

Natürlich kann man da je nach Situation alles mögliche optimieren - das war aber nie mein Ziel.
Was ich mir geschaffen hab war ein Skript welches ich einfach duplizieren kann, und welches auch dann funktioniert wenn der JS Adapter nicht beim Start alle States abonniert.

A.

[MartinP]

Vielleicht ist das auch ein "fauler" Garbage Collector, der erstmal "abwartet" bis es eng wird, bevor er aufräumt - da könnte es sein, dass so lange auf dem Peak-Stand der Listengröße für offene Fenster verharrt wird, wie der Garbage Collector Ruhig bleibt, und der Speicherplatz auch bei anwachsender Listenlänge noch passt ...