Binding vs Skript
-
Weiß jemand, ob ein Binding in einer View (derzeit mit VIS1 erzeugt) immer Last auf dem Frontend erzeugt oder nur, wenn die View auch angezeigt wird?
Hintergrund meiner Frage:
- Wenn ich es bisher richtig verstanden habe, wird ein Binding in/von der VIS auf dem Frontend ausgeführt/berechnet und belastet daher z. B. das Smartfon.
- während ein Skript auf dem Server/Backend ausgeführt/berechnet wird und daher z. B. den Raspi belastet.
In meinem Beispiel geht es um eine Koordinatenberechnung für die Positionierung des Basic-String-Widgets (SSO 155°) in einem View, das immer an der Spitze des Windpfeils gezeigt werden soll (an jeder Stelle zeigt es natürlich anderen/ den passenden Inhalt):
Ich positioniere das Widget dazu im VIS-Editor in der Mitte der Windrose und trage unter CSS Algemein/transform ein:
translate({x:alias.0.Wetterstation.Windrichtung;85*Math.sin(x*Math.PI/180)}px,{y:alias.0.Wetterstation.Windrichtung;85*(-Math.cos(y*Math.PI/180))}px)Alternativ könnte ich stattdessen dort ja aber auch eintragen:
translate({0_userdata.0.Wetterstation.Wind.Widget_X}px,{0_userdata.0.Wetterstation.Wind.Widget_Y}px)und die beiden Datenpunkte (Widget_X und Widget_Y, also die relativen Koordinaten für die Anzeigepostion des Widgets) via Skritp berechnen, was ja weniger Mathematik auf dem Frontend erfordert.
Mir ist bewußt, daß beide Varianten die Systeme nicht extrem belasten. Mir geht es eher um "Best practice", denn solange man soetwas nicht "exessiv" nutzt, merkt man den Performance-Unterschied ja auch nicht wirklich.
Ich habe mich bisher für die erstere Methode entschieden, weil ich mir dachte:
- Das Skript läuft zwar auf dem "potenteren" Gerät, dort erzeugt es jedoch immer/oft Last (der Windsensor triggert alle paar Minuten).
- Die VIS/das Frontend wird nur belastet, wenn die View auch wirklich angezeigt wird, was bei mir eher seltener vorkommt.
-
@andersmacher sagte in Binding vs Skript:
In meinem Beispiel geht es um eine Koordinatenberechnung
Was hälst du hiervon :
-
@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.
-
@andersmacher
iobroker/vis und auch der browser/webview sorgen bereits vorbei iobroker läuft die aktualisierung in 2 stufen ab.
-
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.
-
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. -
-
@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? -
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.
-
@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?
-
so wie geschrieben. lieber mehr normale widgets
als alles kombiniert in einem html widgetaber 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. -
@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 verwendenmomentan 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.
-
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 -
@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. (;-)
