Accessing stack traces of an Error object is extremely slow

[bu...@shyp.com]

Hi,

While profiling one of my tests I noticed that accessing the `stack` property of an Error object is extremely slow; anywhere from 5 to 100ms on my pretty new MBP (I can reliably reproduce one test case where it takes 100ms to access the property). I'm running node v0.12.4, however most of the code in my application is written in Coffeescript. Switching `err.stack` and `console.trace()` is just as slow.

Has anyone else observed stack traces that are this slow? Are there any possible workarounds, besides not logging the stack trace? 

Sorry this is a little vague, I can provide more info if I can get hints about where to look.

Thanks,

Kevin 

[Ben Noordhuis]

Do you see the same behavior with io.js? I think you are hitting a
(fixed but not in v0.12) V8 bug.

[Peter Rust]

> any possible workarounds, besides not logging the stack trace?

This might fall under the "not logging the stack trace" category, but I typically only log the stack trace when there is an error. This way I only get the performance hit under infrequent circumstances, via "if (err) return callback(trace(err));" where the trace() function appends the current stack onto the error object's stack property. This happens each time the error gets passed up the callback chain, so that by the time it gets to the top-level caller it has a stack for each level of asynchronicity (see https://github.com/CSNW/async-stacktrace for more details if this approach applies to your situation).

-- peter