1. 6
  1.  

  2. 3

    “Capturing the stack trace takes time (i.e. degrades performance); storing these stack traces requires memory”

    Annnnnd then no evidence about how much time. Is it an hour? a nanosecond? who knows.

    1. 3

      It’s non-negligible. In compiled code you just have the base pointer / return address chain on the stack, so to generate a stack trace you need to look up each stack frame by instruction pointer. A range map stores which instruction pointers correspond to which lines of code. So you follow the linked list of stack frames via saved base pointer, looking up saved return address in the range map, saving each source location struct in an array, until you hit the top of the stack. It’s solidly a cold-path strategy designed to allow the fast path to be as tight as possible, the fast path being normal code execution. Probably adds a few hundred instructions and a few dozen memory accesses in the common case.

      It’s difficult to say how expensive that would be in practice. In the browser, if you even measured a .1% improvement I’d be surprised, since I’d expect most promises to wrap expensive operations, and you just don’t have that many concurrent expensive operations in flight in a browser.

      On the server it could be more significant, if your application is some kind of highly concurrent network reactor with little logic besides managing connections. In that case, dealing with promises could be a nontrivial amount of CPU time.

      I think it’s philosophical, “don’t be wasteful out of pure stupidity and nothing else” or something.