Reputation: 929
I'm a little new to JavaScript. I've used it here and there on the client-side for a while, but now I am adventuring into server-side Javascript. This question is about Javascript objects, regarding their creation and the efficient definition of their properties.
I've seen (several times) that creating an object as var o = {};
is now preferred over var o = new Object();
for performance reasons. Are there differences in performance in how you add properties to an object?
For instance, is there any difference in performance between this situation:
var o = {
thing1: "yardigooven",
thing2: "goovenyardi",
};
and this situation?:
var o = {};
o.thing1 = "yardigooven";
o.thing2 = "goovenyardi";
I'm assuming the first case is preferred, but I want to make sure before I write all of my object definitions that way.
Thanks.
Upvotes: 4
Views: 3510
Reputation: 43979
There is one important optimization in V8 (and possibly other JavaScript engines) that is called inline caches:
const x = {
foo: 1,
bar: 2
};
If this object never changes, this optimization allows you to get fast access to properties (x.foo
). Without optimizations, the runtime would need to do a dictionary lookup each time. But with the optimization, the lookup is closer to compiled languages where the data structure is statically known.
Back to your question: for this important optimization to kick in, it will not matter if you initialized the object as above or like this:
const x = {};
x.foo = 1;
x.bar = 2;
There may be minor performance differences, but you will get the important optimization in both cases. Thus, if you keep using the object, I would not expect significant differences.
However, there are a couple of non-obvious pitfalls, which will prevent the optimization (depends on the JavaScript runtime but should apply to V8).
delete
The reason for 1) is that if you add a property, it will internally create a new hidden class. So, you will get a second hidden class if you would have swapped the initialization order:
const y = {};
y.bar = 2;
y.foo = 1;
Note there is a semantic difference between x
and y
(e.g. Object.keys(x) -> ['foo', 'bar']
but Object.keys(y) -> ['bar', 'foo']
).
But otherwise, it is better for performance to always initialize fields in the same order; especially if you have multiple fields. With fewer permutations, the number of hidden classes is also lower. That helps the inline caches optimization.
Regarding delete
: the optimization can handle new fields being added (up to a certain number), but if you delete fields, it will fallback to dictionary lookups. To the best of my knowledge, once it is in that state, the object will never be able to reach fast lookups again. That is why delete
may come with a performance hit in certain workloads. In that case, consider keeping the field, but zeroing it out (e.g. setting it to null
).
Upvotes: 1
Reputation: 47776
First of all, var o = {};
and var o = new Array();
aren't the same. The first initializes an object, the second an array. var o = {};
and var o = new Object();
are equivalent.
Now about the performance of using an object literal instead of adding the properties after. Which one is fastest? The answer is, we don't care, and you shouldn't either. If there is a difference in performance, it will be so small that it will never impact, even if you create 1 million objects at once, which is unlikely to ever happen.
This is called premature-optimization, and is the bane of many intermediate programmers. Don't worry about optimizing anything unless you start having performance problems. Then you use a profiler to detect where the bottleneck is and solve it. Just worry about making your app.
For completeness' sake, here is a test I ran on jsperf. In my browser, Chrome 15, the object literal initialization was 53% faster. Wow, 53%, that's huge right? Except if you put your mouse over the tooltip for the test that uses properties after initialization, you'll see it says something like
Ran 681,285 times in 0.077 seconds.
Your numbers may differ, but you'll be able to observe that the method considered slowest still goes pretty fast by any standards. I think it's safe to say that both are fast enough for any purpose. Just use the one you prefer.
Upvotes: 12
Reputation: 156434
Heed the advice of others about premature optimization - meaning don't focus on these sorts of implementation details which will likely vary greatly between different JavaScript interpreter implementations.
However, based on this JSPerf benchmark and a sample size of one (on Chrome/Mac OS X), the object literal form (o = {foo:'bar'}
) is much faster than setting properties after construction (o={}; o.foo='bar'
).
Upvotes: 3