204

Guys I have a couple of questions:

  1. Is there a performance difference in JavaScript between a switch statement and an if...else?
  2. If so why?
  3. Is the behavior of switch and if...else different across browsers? (FireFox, IE, Chrome, Opera, Safari)

The reason for asking this question is it seems that I get better performance on a switch statement with approx 1000s cases in Firefox.


Edited Unfortuantly this is not my code the Javascript is being produced serverside from a compiled library and I have no access to the code. The method that is producing the javascript is called

CreateConditionals(string name, string arrayofvalues, string arrayofActions)

note arrayofvalues is a comma separated list.

what it produces is

function [name] (value) {
  if (value == [value from array index x]) {
     [action from array index x]
  }
}

Note: where [name] = the name passed into the serverside function

Now I changed the output of the function to be inserted into a TextArea, wrote some JavaScript code to parse through the function, and converted it to a set of case statements.

finally I run the function and it runs fine but performance differs in IE and Firefox.

4
  • 1
    I would suggest a code sample to examine what's optimal. I mean, there's gotta be a reason you're asking this, right? Commented May 27, 2010 at 16:34
  • 1
    Please post what you're up to, because there are very few cases in my long experience for which I'd say a 100-case switch statement or a 100-part if/else series was a good idea. Commented May 27, 2010 at 16:40
  • sorry guys not 100s but thousands of conditions Commented May 27, 2010 at 17:04
  • 4
    Everyone, thanks for the input. But my problem wasnt actually the difference between the if and swith statments. It was the code running inside the statement. +1 to all of you for your help. Sorry for the inconvienience. Sometimes you just need to talk things out with another person to find the solution. Commented May 27, 2010 at 17:34

10 Answers 10

144

Answering in generalities:

  1. Yes, usually.
  2. See More Info Here
  3. Yes, because each has a different JS processing engine, however, in running a test on the site below, the switch always out performed the if, elseif on a large number of iterations.

Test site

Sign up to request clarification or add additional context in comments.

17 Comments

If you want a TLDR of when to use which conditionals here is a direct link to a segment in the article addressing that: oreilly.com/server-administration/excerpts/even-faster-websites/…
@Tommy Good article, thanks for sharing. However the article states that there is a negligible performance difference between switch and if/then statements in JS. The article states this is due to spotty switch optimization and the different ways different JS engines function. Quote: Since most JavaScript engines don’t have such optimizations, performance of the switch statement is mixed.
Is anything quantifiable shown in this description? It reads like a lot of "best practices/premature optimization" conjecture. It was also written 7 years ago, so javascript optimizations have changed tremendously in this time. In compiled languages, the performance difference between these three operations is "almost never significant enough to care". Don't bother optimizing things that won't affect actual performance. Optimize readability.
@Tommy «See More Info Here» gives 404, what was there?
@LogicDaemon - IIRC is was a link to some oRielly textbox that got into some indepth JS performance considerations / discussions
|
80

Sometimes it's better to use neither. For example, in a "dispatch" situation, Javascript lets you do things in a completely different way:

function dispatch(funCode) {
  var map = {
    'explode': function() {
      prepExplosive();
      if (flammable()) issueWarning();
      doExplode();
    },

    'hibernate': function() {
      if (status() == 'sleeping') return;
      // ... I can't keep making this stuff up
    },
    // ...
  };

  var thisFun = map[funCode];
  if (thisFun) thisFun();
}

Setting up multi-way branching by creating an object has a lot of advantages. You can add and remove functionality dynamically. You can create the dispatch table from data. You can examine it programmatically. You can build the handlers with other functions.

There's the added overhead of a function call to get to the equivalent of a "case", but the advantage (when there are lots of cases) of a hash lookup to find the function for a particular key.

2 Comments

Your strategy is good and I use it oftenly. But as pointed by @Michael Geary stackoverflow.com/a/45336805/5936119, the map variable must be declared outside the dispatch context otherwise it will always be re-evaluated.
@DanielSantana true but I doubt that's significantly expensive. In particular, once a function is initially parsed the code itself need not be regenerated, as the text is static.
35

The performance difference between a switch and if...else if...else is small, they basically do the same work. One difference between them that may make a difference is that the expression to test is only evaluated once in a switch while it's evaluated for each if. If it's costly to evaluate the expression, doing it one time is of course faster than doing it a hundred times.

The difference in implementation of those commands (and all script in general) differs quite a bit between browsers. It's common to see rather big performance differences for the same code in different browsers.

As you can hardly performance test all code in all browsers, you should go for the code that fits best for what you are doing, and try to reduce the amount of work done rather than optimising how it's done.

1 Comment

This is the answer I did not come looking for, but accepted as the definitive answer to my long-lasting "if vs switch" inner debate.
14

Pointy's answer suggests the use of an object literal as an alternative to switch or if/else. I like this approach too, but the code in the answer creates a new map object every time the dispatch function is called:

function dispatch(funCode) {
  var map = {
    'explode': function() {
      prepExplosive();
      if (flammable()) issueWarning();
      doExplode();
    },

    'hibernate': function() {
      if (status() == 'sleeping') return;
      // ... I can't keep making this stuff up
    },
    // ...
  };

  var thisFun = map[funCode];
  if (thisFun) thisFun();
}

If map contains a large number of entries, this can create significant overhead. It's better to set up the action map only once and then use the already-created map each time, for example:

var actions = {
    'explode': function() {
        prepExplosive();
        if( flammable() ) issueWarning();
        doExplode();
    },

    'hibernate': function() {
        if( status() == 'sleeping' ) return;
        // ... I can't keep making this stuff up
    },
    // ...
};

function dispatch( name ) {
    var action = actions[name];
    if( action ) action();
}

Comments

8

Other than syntax, a switch can be implemented using a tree which makes it O(log n), while a if/else has to be implemented with an O(n) procedural approach. More often they are both processed procedurally and the only difference is syntax, and moreover does it really matter -- unless you're statically typing 10k cases of if/else anyway?

4 Comments

7 years later... I don't see how tree implementation is possible, except in a the case of constant numerical case values).
3.5 years later... @Ed Staub Of course that is the case here. Switch statements work with constants. Wether already numbers or whatever, they can be enumerated, so a tree can be constructed.
@trollkotze While constants are most common, case clauses can be any expression. See e.g. stackoverflow.com/questions/3463833/….
Oh, I didn't know that. It's not possible in C, afaik. Only constant expressions allowed there. So I assumed it to be the same in JS.
4
  1. If there is a difference, it'll never be large enough to be noticed.
  2. N/A
  3. No, they all function identically.

Basically, use whatever makes the code most readable. There are definitely places where one or the other constructs makes for cleaner, more readable and more maintainable. This is far more important that perhaps saving a few nanoseconds in JavaScript code.

9 Comments

In javascript especially, the semantics and readability (and therefore the maintainability) trump any localized performance differences between if..else and switch caused by a unique browser version computer hardware and OS combination.
i definitely disagree. as web applications become more and more complex, this difference could be significant for the application and could change dependent on browsers.
The important thing is to write clean, maintainable code. When a performance issue is seen - profile. Then determine which code to fix. Don't sacrifice maintainability for assumed performance issues.
'if else if else ...' is O(n), while 'switch' is either O(1) or O(log(n)). How can you honestly state the difference can never be large enough? Have a million of cases in switch (easily possible if the code is generated) and you'll definitely notice it to say the least.
I downvoted this because I think the generalization made in answer to the first question is incorrect.
|
1

Is there a preformance difference in Javascript between a switch statement and an if...else if....else?

I don't think so, switch is useful/short if you want prevent multiple if-else conditions.

Is the behavior of switch and if...else if...else different across browsers? (FireFox, IE, Chrome, Opera, Safari)

Behavior is same across all browsers :)

Comments

1

It turns out that if-else is generally faster than switch.

See jsPerf.app — Switch vs. if/else — Benchmark created by Jason on January 12, 2012 for more information.

Comments

1

For people still looking for this in end 2024.

Benchmark : https://jsben.ch/B1k4I

Reasons to use if/else if instead of switch :

  • Minify better due to ? : shorthand
  • Usually prevent one useless level of indent
  • Avoid weird behavior with switch variable scope being shared across all cases

Unless you're dealing with a huge number of cases in a performance critical application, and can't use objects, no point using switch i think

Comments

0
  1. Workbenching might result some very small differences in some cases but the way of processing is browser dependent anyway so not worth bothering
  2. Because of different ways of processing
  3. You can't call it a browser if the behavior would be different anyhow

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.