Performance impact of increasing Error.stackTraceLimit?

[Benjamin Pasero]

Hi,

I am wondering what the performance impact would be if I would change Error.stackTraceLimit [1] to a high value (e.g. 1000?). The default of just 10 stack frames is little when the error bubbles through a long chain of promises for example.

This change would be in production code, not just for testing, so I am a little bit nervous of the consequences this would have.

Maybe someone can share some experiences with changing this value. 

Ben

[1] https://github.com/v8/v8/wiki/Stack-Trace-API

[Ben Noordhuis]

Stack traces are built by storing back-references to the JS functions
on the stack. The human-readable stack trace is computed lazily. The
longer the stack trace, the bigger the chance you retain code objects
beyond their natural lifetime (i.e., introduce memory leaks) but that
might be offset by the observation that the bottom of the stack is
often invariant.

You'll also pay a little in CPU time in the stack frame walker but
that's probably tolerable. I assume you're asking this in the context
of VS Code where human perception is the important factor.

[Benjamin Pasero]

 assume you're asking this in the context 
of VS Code

Yes, this would apply to any process in VS Code, including the renderer. 

[Mariusz Nowak]

>The longer the stack trace, the bigger the chance you retain code objects

beyond their natural lifetime

I wonder why would stackTraceLimit influence that (?) The function invocation at bottom of the stack is anyway the point to which execution may return (assuming no exception on the way). Therefore all those objects should be kept in memory isn't it?

What would be a simple example of object that would be freed in case of execution being beyond the stack trace limit, but wouldn't otherwise?

On Monday, March 5, 2018 at 6:29:13 AM UTC+1, Ben Noordhuis wrote: