switchObj performance

[mathiasbynens]

I absolutely love the elegance and reusability of the switchObj pattern (even if it’s slower), but I’d like to get this straight.

See http://twatlr.com/thread/140407213511544833
Here’s @felixge’s test case: http://jsperf.com/object-vs-regular-switch

For my Velocity preso I created this test: http://jsperf.com/switch-vs-object-literal-vs-module/2 But it seemed regular switch was still faster. Any idea what’s up with that?

Rick’s test case only seems to test for the case where foo is a defined key in the switchObj, and doesn’t have the hasOwnProperty check. Perhaps that’s what caused the confusion?

/cc @rwldrn @jdalton @felixge

[felixge]

Worth noting: For my particular use case (fast parsers) I assume that the functionality triggered by the switch case is inlined and not achieved by calling another function. That should obviously give an advantage to the switch approach as there is no need to call a function, but if JS engines optimized the switch object approach I'd love to use it.

[rwaldron]

Rick’s test case only seems to test for the case where foo is a defined key in the switchObj, and doesn’t have the hasOwnProperty check. Perhaps that’s what caused the confusion?

The pattern I'm promoting should be used in cases where you always know that the "case" argument will be "one of these properties" to get full benefit over blacklisted switch. Also, in the newest case, I suspect that the recreation of switchObj for every test run negates the JIT performance boosts that would be gained if it were read once and cached for the lifetime of the program.

Note: I'm also interested in finding the best and most performance approaches, so this conversation is a definitely a good starting point.

[jdalton]

❤️

[felixge]

Also, in the newest case, I suspect that the recreation of switchObj for every test run negates the JIT performance boosts that would be gained if it were read once and cached for the lifetime of the program.

I also ran some tests with a switch object that is only setup once, I saw similar numbers.

Note: I'm also interested in finding the best and most performance approaches, so this conversation is a definitely a good starting point.

+1

[mathiasbynens]

Also, in the newest case, I suspect that the recreation of switchObj for every test run negates the JIT performance boosts that would be gained if it were read once and cached for the lifetime of the program.

I also ran some tests with a switch object that is only setup once, I saw similar numbers.

That’s what I tested as well: http://jsperf.com/switch-vs-object-literal-vs-module/2

The hasOwnProperty function call sure slows things down, but even without it it’s still not the fastest solution in all cases.

Note: I'm also interested in finding the best and most performance approaches, so this conversation is a definitely a good starting point.

+9001

[rwaldron]

This is really interesting - looking back on my original tests, they still show switch as slower then the object pattern - but they're also not accounting for the default: or _default case.

[rwaldron]

I've updated the section to reflect new information regarding the performance of switch with links to updated test results, as well as a link to this thread if anyone is interested in learning more

[pinglikethinking]

It is a little hard to understand