views:

142

answers:

9

I am working on a project which requires some pretty intricate Javascript processing. This includes a lot of nested if-elses in quite a few places. I have generally taken care to optimise Javascript as much as possible by reading the other tips in SO, but I am wondering if the following two constructs would make any difference in terms of speed alone:

if(some_condition) {
    // process
    return ;
}

// continue the else condition here

VS

if(some_condition) {
    // process
}

else {
   // the else condition...
}
+5  A: 

I always go with the first method. Easier to read, and less indentation. As far as execution speed, this will depend on the implementation, but I would expect them both to be identical.

Josh Stodola
I disagree. Maybe a little easier to read, but harder to maintain, even harder when it is not you but any other developer who has to understand the code. That is my opinion, in general terms, about functions having too much "return" points.
Guido
I respectfully disagree with your disagreement. In my experience, using this type of construct has never affected maintainability. If anything, it has made it better; the fewer amount of nested statements tends to increase maintainability for me. I do, however, agree with your remark about having too many "return points". Generally, I only have return points at the beginning and end of the functions. At the beginning for the obvious exclusions, and at the end to serve the function purpose.
Josh Stodola
There is merit to both side. My personal experience is that too many nested if-elses is a nightmare - especially if one of the two conditions is really short and so we can do with a return statement to quickly terminate it. This definitely makes it more readable.
jeffreyveon
A: 

Test it yourself. If this JavaScript is being run in the browser, it will almost certainly depend on the browser's JavaScript parsing engine.

Stefan Kendall
A: 

My understanding is that would not make a difference because you branch with the if condition. So, if some_condition is true, the else portion will not be touched, even without the return.

aubreyrhodes
Do you have numbers to confirm this statement? Remember that javascript isn't generally compiled.
Stefan Kendall
+1  A: 

There won't be any difference in performance I would recommend the second example for maintainability. In general it's good practice to have one and only one possible exit point for a routine. It aids debugging and comprehension.

Chris Clark
+1  A: 

"Profile, don't speculate!"

  1. you're putting the cart before the horse (maintainability by humans trumps machine speed)
  2. you should drive your optimization efforts by measurements, which means

    • you should time the execution yourself; it'll obviously differ in different browsers and versions
    • you should only optimize for speed the hotspots of your application (see point 1)
just somebody
+1  A: 

Maybe slightly, but I don't think it will be measurable unless the rest of the function involves "heavy" (and otherwise redundant since I assume that a return would give same result) js calls.

As a side note, I think this is unnecessary micro optimization, and you should probably look elsewhere for performance improvements, ie profile the script through Chrome's developer tools or Firebug for Firefox (or similar tools) and look for slow/long running calls/functions.

Sune Rievers
+3  A: 

In many languages, is a common practice to invert if statements to reduce nesting or use preconditions.

And having less nesting in your code improves code readability and maintainability.

CMS
A: 

While it depends on the JS implementation of the running browser, there should not be any notable difference between them (in terms of speed). The second form is preferable since breaking the flow is not a good programming habit. Also think about that in Assambly jump instruction (micro operation) always evaluated regardless of the evaluation.

eyazici
Citation needed (for "not a good programming habit")! :-) It's a matter of opinion whether it's better to nest if-elses or return early; there's no definitive winner just like tabs vs spaces, vi vs emacs etc. Personally I believe it *is* better to return early (as in the first form) but I recognise opinions will differ.
Andrzej Doyle
You are right "there's no definitive winner", but it is far from "vi" vs "emacs"; it is more like "break in for loop" vs "while loop" or "continue in while/for loop" vs "an outer if block". I always prefer the second ones.
eyazici
A: 

Suppose the return takes 1ms versus the nested if taking 0.1ms (or vice-versa).

It's hard to imagine either one being nearly that slow.

Now, are you doing it more than 100 times per second?

If so, maybe you should care.

Mike Dunlavey
Yes, it's called many many times. Or else, I know it hardly makes a difference!
jeffreyveon