In many cases, the non-exception path is as fast or faster than if/then/else. This is because compilers and interpreters tend to be optimized for non-exception paths.
If you actually throw and catch an exception, it might be slower but since most of the time there are no exceptions, the overall result is faster with exceptions. This is because there are no branches in control flow that would slow things down.
The micro benchmark in the original article is meaningless. This should be measured in a real-world situation where the catch is 5-10 levels up from the throw, and there are a lot more throws than catches.
The latest revision is a completely different test. As klodolph explains in another comment, the presumably common case of no exception is generally how try/catch is optimized. So it stands to reason that the exception case would be slower and that there is potential for the non-exceptional case to be faster.
That test is broken. In JavaScript the value of an undefined property will be `undefined`, not `null` so the second test is doing twice the work of the first.
It's a good reminder though, because sometimes people get ideas in their heads about using exceptions for something other than, well, exceptions, and this is usually a bad idea.
Comments
And? This isn't very surprising. Exceptions are slower than regular/shortjump control-flow.
In many cases, the non-exception path is as fast or faster than if/then/else. This is because compilers and interpreters tend to be optimized for non-exception paths.
If you actually throw and catch an exception, it might be slower but since most of the time there are no exceptions, the overall result is faster with exceptions. This is because there are no branches in control flow that would slow things down.
The micro benchmark in the original article is meaningless. This should be measured in a real-world situation where the catch is 5-10 levels up from the throw, and there are a lot more throws than catches.
Look at the latest revision: http://jsperf.com/try-catch-error-perf/16
Your "not surprising" result is only valid in Chrome and Opera. Other browsers are faster at try/catch.
The latest revision is a completely different test. As klodolph explains in another comment, the presumably common case of no exception is generally how try/catch is optimized. So it stands to reason that the exception case would be slower and that there is potential for the non-exceptional case to be faster.
That test is broken. In JavaScript the value of an undefined property will be `undefined`, not `null` so the second test is doing twice the work of the first.
It's a good reminder though, because sometimes people get ideas in their heads about using exceptions for something other than, well, exceptions, and this is usually a bad idea.