0

Say there is an object called obj, and it has an attribute named attr. In some function body I access the attribute say three times using a syntax like this (obj.attr). Is there a disadvantage to declaring a local variable const objAttr = obj.attr, and using it in place of obj.attr? I would declare the local variable to avoid the cost of repeatedly accessing attr from its obj. But I am wondering if there might be a disadvantage to creating the local variable for the mere sake of avoiding repeated access calls?

faint-hearted-fool
  • 339
  • 4
  • 14
  • 3
    Imo, the primary benefit of the local variable is simply less typing. occam's razor. programers are lazy/efficient – Taplar Nov 29 '19 at 18:53
  • I thought so too, I just wanted to be certain, and would like to hear differing opinions that might possibly be convincing. – faint-hearted-fool Nov 29 '19 at 18:56

3 Answers3

1

This is called variable caching and, not only is there no disadvantage, the benefit is often more concise code that is easier to read and maintain. There can potentially be performance benefits as well.

Scott Marcus
  • 64,069
  • 6
  • 49
  • 71
  • Talking of performance, local variables would be just somewhere in the stack of the current function and do not require extra address computation, where as field access would be somewhere in the heap and would need additional address calculation. – faint-hearted-fool Nov 29 '19 at 19:01
  • @faint-hearted-fool Well, yes, and that's what I was referring to when I said performance benefits. But in JavaScript, we call the process of resolving a variable, looking through the "scope chain". It's not so much an issue of stack vs. heap. – Scott Marcus Nov 29 '19 at 19:04
1

Their is in fact a slight advantage to creating a local reference to an object attribute, as your function will now only have to look it up on the object once instead of three times.

In modern js their a short cut syntax to do this

const { attr } = obj

Is the same as

const attr = obj.attr
David Bradshaw
  • 11,859
  • 3
  • 41
  • 70
  • *your function will now only have to look it up on the object once instead of three times* <-- That's not entirely correct. It depends on what the value being cached is. If it is a primitive, then yes. But, if the value was another object, then the variable will be storing the memory address of that object and will have to look it up every time. – Scott Marcus Nov 29 '19 at 19:12
0

As mentioned here, in V8 engine, key lookup of an object should be of O(1) time complexity, no matter how large the object is. Hence creating a variable or accessing it using the key should ideally make no difference in performance.

This is also due to the fact that no matter which route you take, the full object will have memory allocated during (or before) the function execution. Hence from a garbage collector POV you are not saving any memory usage. Not to mention if you are creating a new variable, you are adding to the memory footprint, but let's assume that's negligible compared to the full object.

Now, as mentioned above, creating a variable has its own other benefits such as repeated usage could make your code cleaner, but from a performance POV, you shouldn't be seeing much change.

Adding a link to a similar question asked before.

Easwar
  • 5,132
  • 1
  • 11
  • 21
  • The post you cite is nearly 9 years old. Also, that post doesn't seem to actually be relevant to this question. Variable caching simply comes down to a shortened scope chain, which has performance benefits. Whether they are big enough to notice really depends on the particular use case. – Scott Marcus Nov 29 '19 at 19:21
  • @ScottMarcus As you said, the benefits of shortened scope may depend on the usecase. If the user is looping n number of times, keeping a variable is recommended. But say its a constant time usage, there shouldn't be much difference, because it also takes time to create a new variable. I've updated the answer with one more link. – Easwar Nov 29 '19 at 19:34
  • *But say its a constant time usage* <-- I don't know what you mean by that. Also, the processor time it takes to create a new variable is non-zero, but without a doubt much less that resolving a value through the scope chain. In short, variable caching (more often than not) does increase performance, the question is just whether it's enough to make a noticeable difference. There really is no downside to it. It's considered one the best, best-practices you can do in JavaScript. – Scott Marcus Nov 29 '19 at 19:37
  • Also, that additional link you shared shows a benchmark where the cached item is, itself an object. As I pointed out in my comment to @davidBradshaw, the performance benefit is, in part, determined by what it is your caching and I addressed objects. – Scott Marcus Nov 29 '19 at 19:40
  • By constant time I mean limited number of references that would not change based on some variable. Also there can be cases where it can have downsides. Ex : Say you have `data = {a: {b: {c: {d: 1}}}};`. Returning `data.a.b.c.d` would be better in perf than creating a variable for it and returning that. This was a trivial example with negligible difference, but you get my point right. – Easwar Nov 29 '19 at 19:45
  • *Returning data.a.b.c.d would be better in perf than creating a variable for it and returning that* <-- What? Why? **There is no logical reason that this would be the case.** As I've said, caching will always be faster because of the shorter scope chain. It's just a matter of whether the performance increase will be noticeable. You can see this from [this basic test](https://jsperf.com/caching-data/1), the two approaches are about equal all the time. – Scott Marcus Nov 29 '19 at 20:45
  • I tried those tests. Chrome favored caching, whereas Firefox had higher ops for non caching. Again this example is very trivial and it also depends on the browser implementations. – Easwar Nov 29 '19 at 20:58