I have a very basic JavaScript question.

I am writing a program which will generate JavaScript code. for accessing a property of a variable i have two choices:

1. make the property access a static query. i.e.
var result = object.property

OR

2. make the property access a dynamic query, i.e.
var result = object["property"]

The difference it makes to me is that for the first case (static query case) i will have to generate separate code for each property access. whereas in the second case (dynamic query case) i can reuse the same function for every property.

I can decide if i know does this makes any difference in performance?

is obj.property faster or obj["property"]?

May be this also depends on the engine which will be used to interpret javascript, so i must mention that I will be using Rhino as my javascript engine.

So please throw some light on this issue.

Thanks, Regards, VImal

I have a very basic JavaScript question.

I am writing a program which will generate JavaScript code. for accessing a property of a variable i have two choices:

1. make the property access a static query. i.e.
var result = object.property

OR

2. make the property access a dynamic query, i.e.
var result = object["property"]

The difference it makes to me is that for the first case (static query case) i will have to generate separate code for each property access. whereas in the second case (dynamic query case) i can reuse the same function for every property.

I can decide if i know does this makes any difference in performance?

is obj.property faster or obj["property"]?

May be this also depends on the engine which will be used to interpret javascript, so i must mention that I will be using Rhino as my javascript engine.

So please throw some light on this issue.

Thanks, Regards, VImal

• javascript
• performance

• They are both static, thus equal. Go for object.property. – Esailija Commented Jul 20, 2012 at 13:34
• if they are equal then i will go for object["property"] as it is beneficial for me. – weima Commented Jul 20, 2012 at 13:35
• @weima - Note that using object["property"] with a string literal will generate a JSLint error. It will advise you to use the object.property syntax. Also, any time you're concerned with the performance of some JavaScript snippets, you can use jsperf. to test it yourself. – James Allardice Commented Jul 20, 2012 at 13:36
• @weima how is that more beneficial? It's harder to write and read. – Esailija Commented Jul 20, 2012 at 13:37
• @Esailija as i am writing a program which will generate the code, if i generate code like object["property"] i can reuse the same code for many properties. – weima Commented Jul 20, 2012 at 13:41

3 Answers 3

There are no static properties in Javascript, only dynamic property accessing exists.

Properties are always queried in the same way regardless of what syntax you put in your source code file.

Use jshint to remend good source code conventions for your JS files:

http://jshint./

Dot notation is always remended. Use quotation mark notation only if your Javascript property has not id which passes in JS syntax.

I did this test on Node.JS

var obj = {test:"test"}

var time1 = new Date();
var t1 = time1.getTime();  

for(i = 0; i < 1000000000; i++){
  obj.test;
}

var time2 = new Date();
var t2 = time2.getTime();

console.log(t2-t1)

var time3 = new Date();
var t3 = time3.getTime();

for(i = 0; i < 1000000000; i++){
  obj["test"];
}

var time4 = new Date();
var t4 = time4.getTime();

console.log(t4-t3)  

I find both perform almost the same, with obj.test performing a tiny bit better than obj["test"]

Emphazise code reusability and maintainability. When you are done, and IF it runs slow, try to see WHERE it is running slow and better it.

So, is there any difference between object.property and obj["property"] in terms of eficciency? I don't think so, but mostly I don't think you should bother until you have encountered a performance issue with your finished, working code. This last part should be your worry.

And even if you find out that your code runs slow, I bet you this will NOT be the reason.