JavaScript object reference caching

Question

We have a lot of objects in our code base that are name spaced to avoid collision.

Example : App.local.view.MyView...

In most of the places i have seen in the code base we use the full path to get a reference to the object and this is repeated multiple times within the same function.

   Example : 
   function hello() {
       App.local.view.MyView.render();
       ...
       ... 
       App.local.view.MyView.reset();
   }

I wanted to understand if storing a reference to the object as below

var MyView = App.local.view.MyView;

would have any improvement in the performance. What makes me ask this question is form my understanding modern browsers like chrome do some optimization automatically for us behind the scenes.

You could try testing it yourself: https://jsperf.com/ But I doubt it will make very much difference performance-wise, but it may help a lot with readability. — Matt Burland, May 28 '15 at 19:47

Mulan · Answer 1 · 2015-05-28T20:17:41.997

5

It will be an improvement, but we're talking a completely negligible one.

It takes time to lookup a property of an object, but it's really quite fast.

If you're doing this for performance reasons, don't.

If you're doing this to make your code more readable/maintainable, then that's OK.

EDIT:

I created a benchmark to test this: Run the benchmark

var data = {a: {b: {c: {d: 1}}}};
var cache = data.a.b.c.d;

// uncached 901,326,988 ±1.03% fastest
// cached 879,568,962 ±0.95% 2% slower

// Chrome 41 on OSX 10.10

Well that's surprising !

Turns out it's faster to just call

data.a.b.c.d + 1

Instead of

cache + 1

I'm sure this varies based on implementation of JavaScript. Providing a specific reason for why this occurs will be left to other genii that dig around in js engine internals.

So with that in mind, my recommendations above stay the same:

If you're doing this for performance reasons, don't — it's actually slower.

If you're doing this to make your code more readable/maintainable, then that's OK — the performance cost is worth the value of more legible code.

edited May 28 '15 at 20:17

answered May 28 '15 at 19:48

Mulan

129,518
31
228
259

This may be partially true but local variables can be much much faster in special cases. Like massive loops, for example. – EvilZebra May 28 '15 at 19:50
@Evilzebra thanks, I made a remark about that. It's still mostly negligible. – Mulan May 28 '15 at 19:57
@naomik Is is negligible to the point it certainly is overtaken by the extra memory usage to declare one more variable, or is that also equally negligible? – Luan Nico May 28 '15 at 20:04
@LuanNico, declaring a variable does cost time too; but again, this is extremely fast. However, if you we're running it in a loop that needed to be optimized, the variable should be defined outside of the loop. – Mulan May 28 '15 at 20:08
I misreported the benchmark results at first. I accidentally flipped the results. For whatever reason, the "uncached" object property access is marginally faster. – Mulan May 28 '15 at 20:18

Robert Rossmann · Answer 2 · 2015-05-28T20:03:34.247

This is implementation-specific and depends heavily on the underlying JavaScript engine.

For example, v8 engine (Chrome & maybe others) uses so-called hidden classes for JavaScript objects. This has the benefit that each object's property is known to be at a fixed offset in the memory and thus accessing an object's property is very fast.

On the other hand, some implementations (I only work with node.js so I do not have any particular browser references that use this method, but Firefox seems to be using this method - see below) may use dictionaries to map objects' properties to their memory locations. Dictionary lookups require more operations (more CPU cycles) and so they are somewhat slower.

In general, however, we are talking about extremely small difference.

To summarise, performance-wise this has almost no impact on your code performance. However, code style-wise, it can improve readability and maintainability of your code.

This jsperf (courtesy of @naomik) seems to support this - when run in Chrome, the difference is about 5%, whereas for Firefox it is a whopping 29%.

JavaScript object reference caching

2 Answers2

Linked