Subject: dojox.lang.Observable performance (was Re: overriding attribute access)
Newsgroups: gmane.comp.web.dojo.devel
Date: 2008-04-08 03:12:17 GMT (34 weeks, 2 days and 16 minutes ago)
>> Will do some perf tests.
First one for each browser is normal access, the second is using
getters/setters ("observed").
IE8:
normal object property access/modification time:
0.00027ms -
"Observed" object property access/modification time:
0.028ms -
FF2:
normal object property access/modification time:
0.00010ms
"Observed" object property access/modification time:
0.012ms
FF3:
normal object property access/modification time:
0.00006ms
"Observed" object property access/modification time:
0.0035ms
Safari 3:
normal object property access/modification time:
0.00005ms
"Observed" object property access/modification time:
0.00084ms
Both IE and FF show roughly 100 times slower performance with observed
access. It is interesting that IE is using the VBscript hack, but FF is
using real getters/setters. VBscript getters/setters are indeed very slow,
but proportional to the normal object access, not really slower than FF's
getters/setters. If you are waiting for real getters/setters in IE to
improve performance, I wouldn't hold my breath. Real getters/setters are
necessary to lift the numerous hideous restrictions, but may not help with
performance.
Safari is in a different world. Real getters and setters and insanely fast.
Seems like it was just a couple years ago that I didn't even consider Safari
a real browser considering it didn't even implement "hasOwnProperty"...
I ran the tests for property access and modification separately, but the
results were almost identical in all browsers. I thought maybe modification
was slower, but I guess not.
Of course, in some applications, property access to an object may be
infrequent, or overshadowed by other expenses (like DOM access), and the
"quality" of the interface may be more important. Bottom line, before you
build a tower, you better the count the cost, and the cost of using
getters/setters to "observe" is about 0.028ms in IE...
As far as using this for dijits, I must admit I do not know this area enough
to offer any advice. For dojo.data impls, I would only consider using it in
for a very slim limited set of applications with the limitations. On the
otherhand, I am hoping to use this for creating policy-based secure DOM
wrappers as part of the dojox.secure project that I would like to build. I
think it is a great fit for that.
In case you want to see my test code, it was roughly this:
function perf(t){
var Observable = new dojox.lang.MakeObservable(function(obj,i) {
return obj[i];
},function(obj,i,value){
obj[i] = value;
},function(scope,obj,i,args) {
return obj[i].apply(scope,args);
});
var obj = {foo:"bar",bar:'foo'};
var newObj = Observable(obj);
var start = new Date().getTime();
for (var i = 0; i < 1000000;i++) { // normal access
var a = obj.foo;
}
console.log(new Date().getTime() - start);
var start = new Date().getTime();
for (var i = 0; i < 1000000;i++) {// observed access
var a = newObj.foo;
}
console.log(new Date().getTime() - start);
var start = new Date().getTime();
for (var i = 0; i < 1000000;i++) { // measure the loop time itself
}
console.log(new Date().getTime() - start);
},