> > assume you're asking this in the context > of VS Code > Yes, this would apply to any process in VS Code, including the renderer.
On Monday, March 5, 2018 at 6:29:13 AM UTC+1, Ben Noordhuis wrote: > > On Fri, Mar 2, 2018 at 5:55 PM, Benjamin Pasero > <benjami...@gmail.com <javascript:>> wrote: > > 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 > > 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. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
