erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[HCS]

Und das Highlight: ich wollte ja nur mal schnell einen reconnect in den Treiber einbauen, weil ich zu faul war, nach einem FHEM-Neustart zum Tablet zu laufen.

Erkenntnis: Faulheit wird mit Arbeit bestraft. 

Ich werde mal anfangen, einiges gedanklich vorwegzunehmen ...

[herrmannj]

so isses. Immer wenn jemand sagt "Freiwillige vor" - einen Schritt zurück treten. Das muss ein Reflex werden! Spass beiseite: bist ja nicht alleine 

[cruser1800]

Würde gern mithelfen! Bewundere aber eure Programmierfähigkeiten, kann hier bestenfalls beim testen helfen!

[herrmannj]

http://jsperf.com/jquery-event-delegation

Eindrucksvoll - würde aber auch bedeuten die widgets umzuschreiben. Und ich bin mir nicht sicher on das geht. So vielleicht ? : $('a').on('update'... ?

[bgewehr]

Ich raffs noch nicht ganz, wir nutzen doch Delegation in SV und nicht find()...

[herrmannj]

ich auch nicht ganz. Denke der Unterschied liegt darin das in sv das delegate (was intern dann auch ein 'on' macht) an 'document' gebunden ist. Find interpretiere ich als Ersatz für die den selector - der Hauptunterschied ist, glaub ich, wo das delegate (on) dann hängt. Nur Hyptothese, und so hab ich HCS verstanden ...

[HCS]

Alle eventhandler hängen oben am document (parallel) und haben selectors. Jedes event muss hoch bubbeln und oben beim document alle selectors evaluieren, die es gibt. Das braucht Zeit. Genau das beschreibt auch die von mir zitierte jquery Doku.

Es wäre mal interessant, aus der widget.js alle widgets rauszuwerfen, die man nicht braucht, was ja die Anzahl der selectors, die im Spiel sind deutlich reduziert.
Da werden immerhin 50 delegates drangehängt, deren selector jedes mal ausgewertet werden muss, wenn ein GAD aktualisiert wird.

Oder mache ich jetzt einen Fehler bei der gedankliche Vorwegnahme?

[fidel]

Könnte vielleich noch jemand mal den experimentellen Treiber probieren, was er an der Geschwindigkeit ändert, verglichen mit dem Domotiga.

Habe den Treiber mal getestet.
Auf nem Rechner macht es kaum einen Unterschied. Auf nem Smartphone bzw.  Tablet ist der Treiber wesentlich schneller. Ich habe jedoch nur wenige Gads.

[herrmannj]

@HCS
ick wees et nich jenau,

Mit jquery kann ich schon, aber nicht umsonst findet man die 5 Millionen jqeury performance how to im Netz. Da ist halt Raum für Spezielisten. Ich befürchte nur wenn da einer in der loop wär dann hätte der oder die schon mal die Finger gehoben. Wird an uns hängen bleiben ...

Mal abstrkt gedacht: wenn man das event direkt zustellen könnte wäre der Job ja erledigt ? Meinst mit rigger könnte was gehen ? Also zB $('a').trigger( ... oder vielleicht sogar object.trigger

http://api.jquery.com/trigger/

[herrmannj]

den gibts auch noch. Da steht das der nicht bubbled und nur das erst element trifft (das könnte man ja handlen ... und dadurch isser ja noch mal schneller)

http://api.jquery.com/triggerHandler/

Naja, morgen ist auch noch ein Tag.

vg
jörg

n8

[bgewehr]

Moin! Es gibt ja diese Variante

Code Auswählen Erweitern

// ----- basic.button ---------------------------------------------------------
$(document).delegate('a[data-widget="basic.button"]', {


Wo schon ein a ausgewählt ist und diese

Code Auswählen Erweitern


// ----- basic.float ----------------------------------------------------------
$(document).delegate('[data-widget="basic.float"]', {


die ohne Objektfilter läuft. Würde es evtl schon helfen, wenn alle sauber mit dem Objekt formuliert werden, das am Ende auch im widget-html verwendet wird?

Das müsste ja die Menge der selectoren schon mal einschränken, oder?

[bgewehr]

Der basic value ist ohne Objekt:

Code Auswählen Erweitern


// ----- basic.value ----------------------------------------------------------
$(document).delegate('[data-widget="basic.value"]', {


Kann einer von Euch mal messen, ob es einen Unterschied macht, wenn man statt dessen

Code Auswählen Erweitern


// ----- basic.value ----------------------------------------------------------
$(document).delegate('span[data-widget="basic.value"]', {


Verwendet?

[marvin78]

Kleine Beobachtungen, die ich zwischen dem Aufstehen und dem Aufbruch zu einer Geschäftsreise machen konnte:

Der Testtreiber bringt auf einer Testseite mit etwa 100 gads (vornehmlich basic.value) eine deutliche (fast unglaubliche) Verbesserung gegenüber Standard-FHEM und auch Domotiga-Treiber.

Das Kürzen der nicht benötigten Widgets aus der widget.js und das "Zusammenlegen" einiger selbst entwickelten Widgets bringt tatsächlich auch eine sichtbare Verbesserung.

Delegate ist schneller als live. Bei on war ich nicht direkt sicher, wie ich das implementieren kann und dann ging mir auch die Zeit aus. Auch den direkten Selector auf das Element hätte ich noch gerne getestet, kam aber nicht mehr dazu. Das sind hier alles immernoch keine empirischen Messungen aber ich hatte leider keine Zeit, dazu etwas zu bauen.

[HCS]

Der Testtreiber bringt auf einer Testseite mit etwa 100 gads (vornehmlich basic.value) eine deutliche (fast unglaubliche) Verbesserung gegenüber Standard-FHEM und auch Domotiga-Treiber.

OK, damit ist das erwartete Ergebnis eingetreten. Ist das von der Geschwindigkeit das, was Du Dir vorstellen würdest?
Schade, dass das so nicht machbar ist.

Das Kürzen der nicht benötigten Widgets aus der widget.js und das "Zusammenlegen" einiger selbst entwickelten Widgets bringt tatsächlich auch eine sichtbare Verbesserung.

Damit bestätigt sich meine Theorie.
Da sie leider wohl stimmt, bedeutet das aber, dass die Widgets auf keinen Fall so bleiben können, wie sie sind.

Das sind hier alles immernoch keine empirischen Messungen aber ich hatte leider keine Zeit, dazu etwas zu bauen.

Wenn man die "Spaßbremse" raus hat, muss man eigentlich gar nicht mehr messen, die Veränderung sieht man so deutlich, dass man weiß, dass es OK ist 
An alle, die dazu was ausprobieren: Auf einem ordentlichen PC, Laptop, ... merkt man da nicht so viel, auf Telefonen und Tablets ist es dagegen gravierend.

[bgewehr]

Sagt mal, man kann ja den JS code auch in einem Script Tag im widget html unterbringen und auf die widget.js ganz verzichten. Das würde einerseits bedeuten, dass die Skripte nur für die verwendeten Widgets geladen werden, andererseits aber, dass sie für jede Verwendung des Widgets angelegt werden, oder greift da irgendeine Optimierung?