On Fri, Dec 19, 2014 at 9:35 PM, Ori Livneh ori@wikimedia.org wrote:
Chrome's profiling tools continue to flag try / catch blocks because they are ineligible for certain types of optimizations. We've discussed it before on this list, but I don't think we ever quantified the performance penalty (or even confirmed its existence), but I think that doing so should probably be a prerequisite to this change.
There are usually three ways exception handling can be slow: 1. entering/exiting the try block takes some time 2. throwing/catching an exception takes some time 3. the optimizer bails out on functions containing try/catch
Given that we are talking about wrapping modules, so the function containing the try/catch block is invoked once per module per page load, I don't think any of these should be relevant.
The first one will be more interesting for wrapping event handlers (something that would be also needed to replace window.onerror), since some event handlers like mousemove or scroll are invoked very frequently. I haven't found any claim that that is a significant performance hit, though; the usual claim is that you will be fine as long as you make sure that your try/catch block is not in the same function as any code that could be significantly improved by optimization.
E.g. bluebird has a pretty good discussion on optimization blockers: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers This jsperf test also does not show much difference: http://jsperf.com/try-catch-performance-overhead