views:

50

answers:

1

Hi Folks,

I'm wondering about access times on object members. More precisely, I'm benchmarking access times on the window object. I believe I can explain most behavior here on my own, but I'd feel better to hear some comments.

Usecase: Different access times on different propertys ?

I'm benchmarking on Firefox 3.6.8 (windows), the simple measuring code looks like:

var loop = 100000;

console.time('bench');
while(loop--){
   if(window.JSON)
      var foo = 0;
}
console.timeEnd('bench');

The first strange thing is, it makes a different which property I'm looking up. For instance, window.JSON seems to be faster to access, than window.localStorage. There are other propertys/methods which can get accessed even faster.
Since there is no specification or defination within in the the ECMA-262 Language Specification, which order keys must have in an object, I guess each browser vendor implements it's own logic in which order keys are stored in memory.
Could this be an explanation for this behavior? Like, JSON is one of the very first keys and location is more at the end? (In my test environment at least)

--

Another thing I noticed is, that calling if(JSON) is slightly faster than if(window.JSON). If we forget about that you always should do the second call because of possible reference errors, those calls should have the same access time. I'm aware of ECMAscripts behavior on nested member lookups (A nested member will cause the Javascript engine to go through the object member resolution, each time a dot is encountered), so window.location.href must be slower than location.href, but in this case.. is there a difference between JSON and window.JSON ?

To end this, the fastest way to know whether or not the window object owns a specific property/method is to use the IN operator. That is about 10 times faster for the above examples.

+2  A: 

The first strange thing you notice might have to do about how host objects are implemented by the browser.

localStorage is a host object, provided by the environment, JSON on the other hand, is a built-in object provided by ECMAScript.

Try to resolve another built-in's and you will get more or less the same results than with JSON.

Now, the difference about JSON vs window.JSON:

window is just a property on the global object that points to itself, when you access the window identifier the name resolution process takes place to find it.

Basically referencing:

JSON;

Involves only one identifier lookup (in the scope chain), and:

window.JSON;

Involves an identifier lookup (window) and a property lookup (window.JSON).

CMS
@CMS: Does the `host object` concept also explain, why the access on `window.outerWidth` takes three times as long as the access on `window.setTimeout` (for instance) ?
jAndy
@jAndy, both, `outerWidth` and `setTimeout` can be considered as host-objects, `outerWidth` is presumably implemented as an *accessor property*, when you access it a getter function is executed, and since it's related to the DOM layout, the current value (the measurement in pixels) must be recalculated, causing a **reflow** (See: [1](http://dev.opera.com/articles/view/efficient-javascript/?page=3#reflow) [2](http://www.nczonline.net/blog/2009/02/03/speed-up-your-javascript-part-4/) [3](http://stackoverflow.com/questions/510213/) ), while `setTimeout` is simply a function object.
CMS
@CMS: pretty interesting, I forgot about the fact that reflows can happen even on accessing a computed style. Anyways, in Nicholas blog, Dean Edwards is doubting that. But then again, if my measuring results are true, it looks like an ultimate fact for a reflow on accessing `outerWidth` (for instance). Might be browser dependent too? Thanks anyway!
jAndy