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

[herrmannj]

Mein Vorschlag wäre erst ein mal zu versuchen das ohne impact auf widget.js hinzubekommen. Weil, wenn wir da jetzt garvierend umbauen dann kannste eben auch nicht mal einfach ein (zB) uzsu widget irgendwo aus einem git holen und das mal eben reinkopieren.

Ich könnte mir vorstellen das http://api.jquery.com/triggerHandler/ uns da schon weiterbringen könnte.

Jetzt:
driver bekommt ein update von fronthem und kippt das als event in den DOM. Im DOM bubbled das event dann durch, speziell an den delegates (die zum Teil ja von jquery auch als emulation abgebildet werden) muss also pro delegate der gesamte Hirarchie durchlaufen werden, mal anzahl der deleagtes. (@HCS, Du bist da ja mittlerweile mit expertise unterwegs, richtig beschrieben?)

Idee:
der driver kippt das event nicht mehr einfach "anonym" rein. Im "monitor" werden die widgets gesammelt (als object) und wenn ein update kommt prüft der driver wo es hingehört und reicht es via "triggerHandler" direkt an das entsprechende widget. Laut api (interpretiere ich so) geht das am DOM vorbei (es werden keine DOM Events ausgelöst, es wird nicht gebubbled). Das sollte imho die Punkte komplett beseitigen ohne (!) die Kompatibilität zu brechen.

@HCS: was denkst Du ? Könnte das funktionieren ? Wenn ja kann ich gern heut Abend mal testen ...

vg
jörg

[bgewehr]

Mein Vorschlag wäre erst ein mal zu versuchen das ohne impact auf widget.js hinzubekommen. Weil, wenn wir da jetzt garvierend umbauen dann kannste eben auch nicht mal einfach ein (zB) uzsu widget irgendwo aus einem git holen und das mal eben reinkopieren.

Jörg, hilf mir kurz: warum nicht? Das eine hat doch mit dem anderen gar nichts zu tun, oder?

[bgewehr]

HCS kannst Du mal die aktuelle Architektur Deiner Plots kurz erläutern?

[herrmannj]

dann hab ich das falsch verstanden. Ich dachte du meinst dass in Hinblick auf die Aktualisierung Zeit. Generell hat sich die Ternnung doch bewährt und ja (Optiminierung), der twig cahce greift dann aber das kennen wir ja.

vg
jörg

[bgewehr]

Das hier klingt interessant, es erspart wieder und wieder im selben DOM zu suchen:

http://stackoverflow.com/a/1883643/2177484

[HCS]

HCS kannst Du mal die aktuelle Architektur Deiner Plots kurz erläutern?

Können wir das verschieben? Drei Dinge gleichzeitig sind zu viel für mich.

[herrmannj]

Das hier klingt interessant, es erspart wieder und wieder im selben DOM zu suchen:

http://stackoverflow.com/a/1883643/2177484

ja genau, das each. Aber HCS hat ja die eventhandler als Achse des Bösen erkannt. vg jörg

[bgewehr]

Können wir das verschieben? Drei Dinge gleichzeitig sind zu viel für mich.

Klar!

[HCS]

Idee:
der driver kippt das event nicht mehr einfach "anonym" rein. Im "monitor" werden die widgets gesammelt (als object) und wenn ein update kommt prüft der driver wo es hingehört und reicht es via "triggerHandler" direkt an das entsprechende widget. Laut api (interpretiere ich so) geht das am DOM vorbei (es werden keine DOM Events ausgelöst, es wird nicht gebubbled). Das sollte imho die Punkte komplett beseitigen ohne (!) die Kompatibilität zu brechen.

@HCS: was denkst Du ? Könnte das funktionieren ? Wenn ja kann ich gern heut Abend mal testen ...

Mir ist spontan nicht klar, wie das gehen soll. Die delegates der widgets hängen momentan (mit der aktuellen widget.js unabänderlich) am document.
Es ist doch momentan schon so, dass das event an das konkrete widget geht, nur dass da halt der handler nicht ist.
Und wenn man den handler dort hin bekommen will, muss man die widget.js ändern.

ja genau, das each. Aber HCS hat ja die eventhandler als Achse des Bösen erkannt. vg jörg

Genau. In dem rasanten Test-Treiber ist das each drin, aber keine Events mehr.

Ich bin mir recht sicher, dass die Zeit an der Stelle drauf geht, an der das event am document die delegates abarbeiten muss, um rauszufinden, bei welchem der selektor passt.
Und solange die delegates in der Art am document hängen, führt da dran nichts vorbei.

Der Test von marvin78 (mit der ausgedünnten widget.js) hat das gezeigt. Wenn am document weniger widgets einen delegate angehängt haben, ist das Richtige schneller gefunden.

[HCS]

Um es nicht als unnötig erscheinen zu lassen, die Optimierung der Abfragen auf dem DOM um die instanz des widgets für einen GAD-Name zu finden kann man dann natürlich auch noch optimieren. Aber so lange das Event pro gad zw. 50 und 100ms kostet, ist das mit seinen 1-2ms eher zu vernachlässigen.

[bgewehr]

HCS machst Du mal die Messung mit Deinen 100 Gads wenn der value mit span ist?

[HCS]

HCS machst Du mal die Messung mit Deinen 100 Gads wenn der value mit span ist?

Ja, muss nur schauen wann, bin mal wieder weit von meiner Entwicklungsumgebung entfernt. 
Und: es sind 300 GADs 

[bgewehr]

So, habe mir jetzt mal mit

Code Auswählen Erweitern


{% for i in 1..10000 %}
{{ basic.value(i, 'FB_user1_todaysec') }}
{% endfor %}


10.000 gads angelegt. )

das Ergebnis ist

5s loading
44s scripting
7s rendering

Ändere ich nun den Code des Widgets von

Code Auswählen Erweitern


// ----- basic.value ----------------------------------------------------------
$(document).delegate('[data-widget="basic.value"]', {
'update': function (event, response) {
$('#' + this.id).html(response + ' ' + $(this).attr('data-unit'));
}
});


auf

Code Auswählen Erweitern


// ----- basic.value ----------------------------------------------------------
$(document).delegate('span[data-widget="basic.value"]', {
'update': function (event, response) {
var item = $(this);
item.html(response + ' ' + item.attr('data-unit'));
}
});


erhalte ich

5s loading
43s scripting
6.5s rendering

also das Gleiche.

Ergo: kleinere Optimierungen am Widget-Code können wir uns sparen, wir brauchen einen anderen Grundansatz!

[bgewehr]

Mit

Code Auswählen Erweitern


$(document).ready(function(){
$('div[data-role="basic.value"]').delegate('span', {
'update': function (event, response) {
$('#' + this.id).html(response + ' ' + $(this).attr('data-unit'));
}
});
});


sind es aber nur noch 20s scripting! Das bringt also schon eher was!

dazu musste ich aber das widget mit einem spezifischen div umgeben, was wiederum auf das Rendering wirkt, aber wir sind ja nur im Test!

Code Auswählen Erweitern


{% macro value(id, gad, unit, tag) %}

<div data-role="basic.value">
<{{ tag|default('span') }} id="{{ uid(page, id) }}" data-widget="basic.value" data-item="{{ gad }}"
data-unit="{{ unit }}">--- {{ unit }}</{{ tag|default('span') }}>
</div>

{% endmacro %}


[herrmannj]

magst Du mal testweiße in der lib//base/widget.js , line #679

das
$(this).trigger('update', [values]);

in das
$(this).triggerHandler('update', [values]);

ändern ob das geht und was bringt ?