Performance hit of newing up Error object in modern Node.js

Question

There are usecases where its necessary to new up an Error object for the purpose of retrieving a stack trace, such as for logging engines or inline debugging.

Is there a heavy performance hit in modern node.js when the Error object is first created or has the smart V8 developers figured out to unwind the stack on demand just when the developer calls <Error>.stack property.

From my probing of the tools, I think that the stack trace unwinding is not executed until <Error>.stack is accessed and it seems a common sense design approach.

Can anybody shed light on this or suggest ways to verify short of debugging the native V8 code?

Answer 1

I built a benchmark test and posted it to my github repo. The results of my tests confirms that the V8 engine behind node.js captures stack information at the point of creation of any Error objects, including sub-classes of Error.

My test is rather elaborate but I wanted to ensure I bypassed any optimizations in V8 for unwinding the call stack. I implemented this by generating a random call stack on each test iteration. I also experimented with calling Error.stack and not calling Error.stack and the impact of this was negligible.

Its interesting to note that the performance hit for construction of the Error, unwinding a stack of just over 10 steps in length and pulling the stack trace as a string costed only about 87 microseconds. The cost for constructing a generic object as about 21 microseconds.

I also found a note on the V8 Github repository Stack Trace API page:

Note that the custom prepareStackTrace function is immediately called at the point when the error object is created (e.g. with new Error()).