Binding vs Skript

[Glasfaser]

@andersmacher sagte in Binding vs Skript:

In meinem Beispiel geht es um eine Koordinatenberechnung

Was hälst du hiervon :

https://forum.iobroker.net/post/619064

[Andersmacher]

@glasfaser Sieht auch schick aus.
Um es auszuprobieren kann ich einfach Deinen Widget-Code in meine View importieren? Ohne Side-Effects? Habe soetwas noch nie gemacht.

Meine "Performance-Frage" bleibt aber offen.

[OliverIO]

@andersmacher
iobroker/vis und auch der browser/webview sorgen bereits vor

bei iobroker läuft die aktualisierung in 2 stufen ab.

1. ganz am anfang werden zuerst alle datenpunkte in allen views eingesammelt und beim server abonniert. ab da löufen dann alle änderungen kontinuierlich an diesen client.

2. aktualisierungen in widgets erfolgen nur, wenn die view in der sich das widget befindet aktuell auch angezeigt wird.

wie du auch geschrieben hast, machen diese art der berechnungen mal gar nix aus. die sind in wenigen millisekunden abgearbeitet.
teuer ist die aktualisierung der DOM (also der Baum in dem die HTML-Elemente organisiert sind und das rendering, also die übersetzung der DOM dann in pixels auf dem bildschirm.

leider fügt iobroker manche widgets immer wieder neu ein.
bei anderen werden aber tatsächlich immer nur die bereiche aktualisiert in dem auch nur änderungen an daten passieren.

[Andersmacher]

@oliverio Danke für Deine Erläuterungen!

Zu Deinem 1.:
Das verstehe ich so, daß ALLE Datenpunkte, die in ALLEN Widgets/Views eines Projekts existieren, nicht regelmäßig als Block, sondern "einzeln" (immer wenn einer dieser Datenpunkte sich verändert hat) vom Server auf den Client "gepusht" werden.

Zu Deinem 2.:
Ob der Client die "gepushten" Daten dann auch nutzt/verarbeitet, bleibt ihm überlassen und hängt davon ab, ob die gerade angezeigte View diesen Datenpunkt verwendet.

Insbesondere 2. hatte ich gehofft zu hören!

Über das mit der/dem? DOM muß ich noch nachdenken, weil mir dazu Hintergrundwissen fehlt. Konkret auf mein Beispiel bezogen:

So wie ich Deine Infos derzeit interpretiere, wäre es also einerseits (annähernd) egal, wie komplex die Berechnungen in einem Binding sind (weil das "in wenigen millisekunden abgearbeitet" ist), andererseits ist es nicht egal, weil, zumindest in meinem Beispiel, durch die Berechnung des Bindings eine neue Position für das Widget entsteht, was alle paar Minuten zu einem "Neuaufbau" des/der? DOM führt, was "nicht ganz so schnell" erledigt wird?
Dabei ist mir natürlich schon klar, daß "alle paar Minuten" auch nur kritisch wird, wenn das viele Datenpunkte beträfe.

Das/Der DOM wird doch aber auch "nur" VIEW-spezifisch erzeugt/aufgebaut und dann doch hoffentlich nur für den angezeigten View - oder?

Daraus würde ich dann insgesamt schließen, daß meine Idee, die Umrechnung der Koordinaten nicht via Skript, sondern im Binding zu machen sinnvoll ist, weil es dann nicht bei jeder Windänderung Last erzeugt, sondern nur, wenn auch zusätzlich die "Wind-View" wirklich angezeigt wird!?

leider fügt iobroker manche widgets immer wieder neu ein.
bei anderen werden aber tatsächlich immer nur die bereiche aktualisiert in dem auch nur änderungen an daten passieren.

Falls das nicht (nur) von ioBroker, sondern vom Widget abhängt:
Gibt es da Empfehlungen für besonders Recourcen-sparende Widgets?

[OliverIO]

@andersmacher

also die DOM (document object model) wird vom browser verwaltet und enthält einfach nur die speichertechnische übersetzung des html-dokuments

https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model

vis fügt diesem dom elemente hinzu oder löscht sie.
an dem wie vis und die widgets aktuell arbeiten kannst du nicht viel ändern.

binding in vis ist ebenfalls eine recht teuere funktionalität (performance), da im hintergrund je binding realtiv viel logik abgearbeitet wird.

daher gilt:

• soviel wie möglich vis widgets verwenden
• so wenig als möglich bindings verwenden
• so wenig wie möglich html-widget verwenden (da das seinen inhalt immer löscht und neu einfügt. insbesondere dann, wenn man da sehr viel inhalt reinschreibt.
• da gibt es evtl noch ein paar andere widget, für die das auch gilt.
  so selten wie möglich die daten ändern. das lässt sich in den datenpunkteinstellungen vornehmen. man muss immer überlegen, ob ein temperatursensor sekündlich oder öfters Änderungen von 0.01 Grad aufzeichnen muss.
• wenn man das im adapter nicht einstellen kann, dann kann man evtl wieder mit trigger und skripten arbeiten, die mit einen treshould arbeiten, also werte in datenpunkte schreiben wenn sie sich um einen relevanten anteil geändert haben. aber da sind wir dann schon im super-optimierbereich. auch benötigt man dann mehr datenpunkte

das hört sich jetzt sehr absolut an und auf einem entsprechend endgerät ist natürlich oft noch viel performance übrig, das man da nicht so sparen muss. aber wenn es eng wird, dann könnte man dahingehend optimieren.

[bommel_030]

@oliverio
Danke für die Erklärung. Hat die Anzahl der (ggf. statischen) Widgets denn auch einen nennenswerten Einfluss? Ich nutze in der VIS relativ intensiv Grid-Views und habe daher viele kleine Views die aussehen wie unten. Mal abgesehen von der Ampel ist der Rest ein einziges HTML-Widget.
Um das mit meinen bescheidenen Kenntnissen hinzubekommen würde ich statt 1x HTML und 1x Bild mindestens 2x Zahlenwidget, 1x Textwidget statisch, 1x Textwidget mit Farbänderung und 1x Bild-Widget benötigen, also 5 statt 2 Elemente.
Würdest du aus Performance-Sicht eher zu mehr Widgets mit weniger Bindings und ohne HTML tendieren oder eher weniger Widgets?

[OliverIO]

@bommel_030

so wie geschrieben. lieber mehr normale widgets
als alles kombiniert in einem html widget

aber wie gesagt. wenn du auf dem client nix merkst, dann musst du dir da aktuell nicht die mühe machen zu optimieren.
erst wenn einer der clients an seine grenzen kommt.

[Andersmacher]

@oliverio Nochmals vielen Dank für Deine ganzen Erklärungen!

Für mich bleibt dann bezüglich

soviel wie möglich vis widgets verwenden
...
so wenig wie möglich html-widget verwenden

momentan als letzte Frage nur noch:
Sind die Widgets im VIS-Editor, die "HTML" im Namen haben, nach Deiner Sprachweise VIS- oder HTML-Widgets?:

Hatte bisher tatsächlich gedacht, daß HTML-Widgets besonders effektiv wären, weil es ja wohl die ureigenste Funktion eines Browser ist, HTML darzustellen und die VIS-App hatte ich immer als "spezialisierten Browser" betrachtet.

[OliverIO]

@andersmacher

das kann man so generell nicht sagen.
html im namen bedeutet nur, das du da eigenes html irgendwie mit angeben kannst. wenn du da im html kein binding einbaust, dann ist alles gut.
aber hängt davon ab wie der programmierer das widget umsetzt.
meine widgets bauen bei änderung eigentlich auch alles neu auf.
aber da sind die änderungen nicht so häufig (tvprogramm,openliga,rssfeed) das das sehr belastet

[Andersmacher]

@oliverio OK, also wie so oft: Komplexer, als man gehofft hat. Dann werd´ ich da wohl erst tiefer einsteigen, wenn die Hardware anfängt zu schwächeln. (;-)