views:

213

answers:

7

Hi, Can you guys help me determine the performance difference of each of these statements? Which one would you use?

  1. Making a new Array using

     - var new_list = new Array();  or
     - var new_list = []
    
  2. Appending element using

    • push('a')
    • new_list[i]; (if i know the length)
  3. Ternary operator or if() {} else (){}

  4. Trying to make isodd function, which is faster
    (! (is_even)) or (x%2!=0)

  5. foreach or normal iteration

one more

  1. a= b = 3; or b=3; a=b;

[edit: Im making a Math Library. So any performance hacks discussions are also welcome :) ]

Thanks for your help.

+4  A: 

I'd suggest you code a simple script like:

for(var i = 0; i < 1000; i++){
  // Test your code here.
}

You can benchmark whatever you want that way, possibly adding timing functions before and after the for statement to be more accurate.

Of course you'll need to tweak the upper limit (1000 in this example) depending on the nature of your operations - some will require more iterations, others less.

Seb
I've done this before, and I've got a few tips. First, test in multiple browsers, as they have different JS engines. Second, you'll need more than 1000 iterations to see any results. And third, you will have to disable script warnings on browsers like IE.
Daniel Lew
Also, each browser tracks time differently (incorrectly). Like, I heard that there are cases when IE will ignore times less than 15ms.
Adhip Gupta
+3  A: 
  1. Both are native constructors probably no difference.
  2. push is faster, it maps directly to native, where as [] is evaluative
  3. Probably not much of a difference, but technically, they don't do the same thing, so it's not apples to apples
  4. x%2, skips the function call which is relatively slow
  5. I've heard, though can't find the link at the moment, that iteration is faster than the foreach, which was surprising to me.

Edit: On #5, I believe the reason is related to this, in that foreach is ordered forward, which requires the incrementor to count forward, whereas for loops are ever so infinitesimally faster when they are run backward:

for(var i=a.length;i>-1;i--) {
    // do whatever
}

the above is slightly faster than:

for(var i=0;i<a.length;i++) {
    // do whatever
}
altCognito
You must be like this javascript ninja. Number 5 is the most shocking. are there any other performance hack that you suggest.
kunjaan
Actually, it's pretty straightforward as to why, you need to evaluate a.length for each iteration, whereas with the first you only grab it the initial go and test against zero.
altCognito
A for #5, there's another alternative based on your first example: var l = data.length; for (var i = 0; i < l; ++i) { //wee } , I think it's is a bit more logical.
Maiku Mori
+1 to Maiku Mori comment. Having a.length inside the for() is only required if you're adding / removing items from the array. If not, just grab it once outside then compare to that value.
Seb
you can put that in one line though: for (var i = 0, l = data.length; i < l; ++i) {...} -- i find this style helps you communicate the scope in which the length variable is being used.
nickf
Also for each iteration in JavaScript is not like the foreach iterators in PHP or C#. It iterates all the properties of an object. So using it for arrays is a really really bad idea.
BYK
What do you mean by "it iterates all the properties of an object"? And if you can't use it for arrays, what is it there for?
Calvin
@Calvin: it behaves like for(in) enumeration, only instead of return the property name it returns the property value. The semantics for this style of iteration actually require a lot of work (see my for..in comments below). For objects it's useful, for arrays it works, but is slower than necessary
olliej
I see. Thank you for explaining it to me.
Calvin
+1  A: 

As other posters suggest, I think doing some rough benchmarking is your best bet... however, I'd also note that you'll probably get very different results from different browsers, since I'm sure most of the questions you're asking come down to specific internal implementation of the language constructs rather than the language itself.

Alconja
+4  A: 

I've always assumed that since (x&1) is a bitwise operation, it would be the fastest way to check for even/odd numbers, rather than checking for the remainder of the number.

Drahcir
+1  A: 

You may be interested in this question and the answers to it

KooiInc
Haha, i thought "ooh that could be interesting" then discovered i was the top answer :-/
olliej
A: 

This page says push is slower. http://dev.opera.com/articles/view/efficient-javascript/?page=2

kunjaan
+2  A: 
olliej