Is a closure for dereferencing variables useful?

Question

I'm not sure whether or when it is useful (to improve performance) to dereference variables.

var x = a.b.c.d[some_key].f;
while (loop) {
    do_something_with(x);
}

seems to be better than

while (loop) {
    do_somthing_with(a.b.c.d[some_key].f);
}

Is that needed or is this done automagically by smart JavaScript engines?

But my actual question is whether I should do this, for example, in a library.

(function() {
    var slice = Array.prototype.slice;

    Function.prototype.x = function x() {
        var args = slice.call(arguments, 0);
        ...
    };
})();

or just

Function.prototype.x = function x() {
    var args = Array.prototype.slice.call(arguments, 0);
    ...
};

The engine can't improve this automatically because it doesn't know whether Array.prototype.slice might change during the run time.

So: does creating a closure for creating the local reference to the slice function make the script faster? Or does the additional closure scope make it slower than accessing the property "slice" of the property "prototype" of Array?

http://jsperf.com Unless you've gone absolutely mad in the number of variables you are creating, I would consider this a micro-optimization in the browser environment. — Jared Farrish, Nov 27 '11 at 20:11
`The compiler can't improve this`, how are you compiling it? — Ash Burlaczenko, Nov 27 '11 at 20:13
Premature micro-optimization is bad. Especially if there's not a real need for it. In a library it might be OK though. — ThiefMaster, Nov 27 '11 at 20:23
Caching property accesses is a good practice and normal thing to do when you are accessing the same property more than once. `for( ;i < something.length ; )` makes me cringe — Esailija, Nov 27 '11 at 20:43
You do see people do this kind of stuff to allow for more aggressive minification (but I think it sacrifices readability too mich) — hugomg, Nov 27 '11 at 20:47
@Ash Burlaczenko: I meant the engines parser. Whats the exakt word for that? — Bergi, Nov 27 '11 at 22:24
Why you are using `Function.prototype.x = function x()` instead of `Function.prototype.x = function ()`? — Wojciech Bednarski, Nov 27 '11 at 22:27
@Šime Vidas: [].slice would be shorter, but I guess the implicit prototype cahin lookup would be significantly slower. In my second example is no loop, but the function is invoked more than once. Otherwise I wouldn't have used Function.prototype — Bergi, Nov 27 '11 at 22:28
@Wojciech Bednarski: Named functions make debugging easier. There's a great article at https://github.com/kangax/nfe — Bergi, Nov 27 '11 at 22:30

jAndy · Accepted Answer · 2011-11-27T20:22:07.983

"Dereferencing" is actually a confusing word for that purpose. Its not that, you just cache some property/method in a local variable. It actually makes no difference whether you do it to access some property/method on a random object or do it with Array.prototype.slice. It makes a lot of sense as soon as you access those deeply nested properties more than once.

Tbh, "modern" browsers do optimize the access quite a lot. All modern js engines uses internal look-up tables to accessed properties. However, you still want to cache those deeply nested stuff since in older engines, it would go the whole way down through all involved objects to resolve it.

One more reason to use local cached references is, that even modern js engines won't use a hash-lookup as soon as some kind of explicit or implicit eval mechanism is used.

Especially Internet Explorer <9 and Firefox 3.5 incur a terrible performance penalty with each additional step into a (prototype) chain.

One word of caution: it is not very recommended to use local caching for object methods (like you do with the slice method). Many objects use this to determine the context in which they are beeing called. Storing a method in a local variable causes this to be bound to global object or null. So always make sure to call such a method with method.call to set the context manually.

As suggested by Jared Farish, I've set up a test case at http://jsperf.com/prop-acess-vs-closures. Both Firefox and Opera seem to be faster when stepping the chain. But: Before I've added the third test case, the chain and the closure approach where exactly equal. — Bergi, Nov 27 '11 at 23:27
@Bergi: that testcase is not quite useful. As I mentioned, if you're going to access a nested property/method only once, it is of course faster to just access it. That testcase calls function, gets the reference and then access the ref. Must be slower, no need to benchmark that. — jAndy, Nov 27 '11 at 23:46

score 3 · Answer 2 · answered Nov 27 '11 at 20:16

If you intend to access a property more than once, consider assigning it to a local variable. However, for modern javascript engines such micro-optimisations will make very little difference, the most important thing thing is to write code that expresses your intent.

score 0 · Answer 3 · answered Nov 27 '11 at 20:21

For this particular issue, you want to have a utility function for that anyway:

function toArray( arrayLike ) {
    return Array.prototype.slice.call( arrayLike );
}

... or if you care about performance:

var toArray = (function () {
    var slice = Array.prototype.slice;

    return function ( arrayLike ) {
        return slice.call( arrayLike );
    };
})();

You don't want to have that slice.call construct all over your code...

Is a closure for dereferencing variables useful?

3 Answers3

Linked

Related