
JS performance: try / catch versus checking for undefined  - ianox
http://jsperf.com/try-catch-error-perf/3
======
judofyr
And? This isn't very surprising. Exceptions are slower than regular/shortjump
control-flow.

~~~
viraptor
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.

~~~
michaelmior
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.

------
quink
Coming from the Python ecosystem, I am utterly horrified by those results. In
fact, I thought the graphs were broken until I got to IE10.

~~~
jerf
Yes, but remember that Python exceptions are cheap not because they are cheap,
but because you are paying for them on every statement _anyhow_ , so you might
as well use them.

------
CJefferson
While perhaps not so extreme, I have found similar behaviour in C++. I worked
on a code base where there was a really nice way of writing an algorithm which
would 'throw' around 100,000 times/sec, and we had to change to something like
this (keep checking return values of functions, and return if they are true),
to get reasonable performance.

~~~
ryanpetrich
Most C++ ABIs use something called zero cost exceptions where the performance
of the uncommon "throws" path is made much slower so that introducing a
try/catch block has no performance penalty when no exception occurs. For
details, see LLVM's docs on the matter:
<http://llvm.org/docs/ExceptionHandling.html>

------
underwater
Worth noting that `undefined` is a variable, and not a keyword.

    
    
       undefined = 1;
       >>> 1
       null = 1;
       >>> ReferenceError: invalid assignment left-hand side
    

It looks like Chrome and Firefox no longer let you assign to window.undefined
any, but I'm not sure is IE has the same restrictions. The correct way to
check for undefined is via `typeof`.

------
simondlr
Why is try/catch so slow?

~~~
klodolph
On SpiderMonkey, a Javascript value is a 64-bit word. In most cases, 32 bits
are set aside for the tag, and one possible tag is 'undefined value'. So
checking to see if a value is undefined is basically a simple comparison, like
checking if a pointer is NULL in C (except very slightly more work).

On the other hand, try/catch requires traversing some kind of structure to
find the catch handler, and exceptions are often allocated somehow. This kind
of action will need to inspect the stack, possibly look at the heap, and
probably do many branches.

Plus, try/catch is not typically optimized for speed of catching exceptions.
Exception handling is typically optimized so that the code path that doesn't
throw an exception is almost as fast as it would be if the exception handling
weren't there. You want people to use your exception handling so they can
write more error-tolerant programs, but they might throw it out if it slows
down their correct code. If you make sure you aren't slowing down the non-
exception path, you may have to make tradeoffs that slow down the exception
path.

The programming language shootout had a test of try/catch performance across
languages. I remember Lisp was at the top, but not as if anyone cares --
try/catch performance isn't relevant to most programs.

OTOH, you may find it interesting that the reverse is true in Python. In
Python, it is almost always faster to catch an exception rather than to check
first. The way CPython checks for errors is by checking the return value of
functions against NULL, after all, which is very fast. Checking ahead of time
requires more Python code, and the Python code is going to be the slow part,
at least on CPython.

~~~
porlw
That's true - how about repeating the test with valid code that DOESN'T throw
an exception.

\- Edit -

Just tried it, it's not even close (on FF4):

tryCatch with undef - ~55,000

ifCheck with undef - ~2,000,000

tryCatch with Object - ~100,000,000

ifCheck with Object - ~2,000,000

So if an error is not thrown the try/catch expression is WAY faster.

------
alexchamberlain
UI Feedback: It would be cool if we could collapse all the Chrome 19.x.x
together.

~~~
clarkdave
If you hit the 'major' filter above the graphs it'll bring them together.

~~~
alexchamberlain
I stand corrected! Thanks.

------
danssig
It doesn't matter. You should signal errors with exceptions, not by returning
undefined no matter how much slower it is. After all, it's supposed to be an
exceptional case.

------
omgtehlion
Note IE10 results.

~~~
mauriciob
So... it IS fast.

It seems they are doing a good work.

------
lucb1e
Note that this is an old revision of the test.

~~~
mistercow
"Old revision" doesn't really mean anything on jsPerf since anybody can create
a new revision which will increment the counter. The main point of having them
numbered is so that you have something stable to link to.

The latest revision (35, as of this comment) is basically equivalent from most
JS engines' perspective, and shows pretty much identical results.

