« Return to Thread: debugging interfaces
Re: debugging interfaces
by Patrick Mueller
::
Rate this Message:
On Aug 13, 2009, at 3:38 AM, Christian Plesner Hansen wrote:
> Having recently implemented stack traces in v8 I can provide some
> input on this from an implementation perspective.
>
> We have pretty strict performance requirements so I did a lot of
> experimentation to see how much information could be collected without
> affecting performance noticeably. The result was that it was feasible
> to collect the value of this, the function being called, and the
> current position within the function. Collecting arguments would have
> been too expensive. Collecting variables would have been much too
> expensive.
I can understand wanting to optimize stack trace generation for the
case of your captureStackTrace() method, but for debugging purposes, I
would think the performance wouldn't matter.
There are a couple of different scenarios I can imagine you might want
stack trace information, with differing expectations of performance
and detail available:
- runtime usage, as the example of captureStackTrace() - should be
highly optimized and may not contain full detail
- debugger usage, where the debugger has actually paused the current
thread of execution, and so performance shouldn't be an issue
(relative to performance of the current thread, which is paused), and
should contain as much detail as is feasible.
- performance tool usage - something between the two - think something
like a profiler which might need more detail than captureStackTrace()
but less than the debugger, and would also have respective performance
requirements between the two as well.
The third seems less important right now.
For the first issue, existing plain old user-land runtime usage, there
was an interesting thread in the webkit mailing list yesterday:
http://thread.gmane.org/gmane.os.opendarwin.webkit.devel/9399/focus=9407
I guess there's no specification for how to get any source location
information from an Error. That would be nice to have, even without a
captureStackTrace(), so that we don't need to have vendor-specific
SPIs to do it. Presumably something like a "source", "line" and
"column" properties, all optional. At least a common place for
implementors to hang this type of information, if they have it.
Patrick Mueller - http://muellerware.org/
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
> Having recently implemented stack traces in v8 I can provide some
> input on this from an implementation perspective.
>
> We have pretty strict performance requirements so I did a lot of
> experimentation to see how much information could be collected without
> affecting performance noticeably. The result was that it was feasible
> to collect the value of this, the function being called, and the
> current position within the function. Collecting arguments would have
> been too expensive. Collecting variables would have been much too
> expensive.
I can understand wanting to optimize stack trace generation for the
case of your captureStackTrace() method, but for debugging purposes, I
would think the performance wouldn't matter.
There are a couple of different scenarios I can imagine you might want
stack trace information, with differing expectations of performance
and detail available:
- runtime usage, as the example of captureStackTrace() - should be
highly optimized and may not contain full detail
- debugger usage, where the debugger has actually paused the current
thread of execution, and so performance shouldn't be an issue
(relative to performance of the current thread, which is paused), and
should contain as much detail as is feasible.
- performance tool usage - something between the two - think something
like a profiler which might need more detail than captureStackTrace()
but less than the debugger, and would also have respective performance
requirements between the two as well.
The third seems less important right now.
For the first issue, existing plain old user-land runtime usage, there
was an interesting thread in the webkit mailing list yesterday:
http://thread.gmane.org/gmane.os.opendarwin.webkit.devel/9399/focus=9407
I guess there's no specification for how to get any source location
information from an Error. That would be nice to have, even without a
captureStackTrace(), so that we don't need to have vendor-specific
SPIs to do it. Presumably something like a "source", "line" and
"column" properties, all optional. At least a common place for
implementors to hang this type of information, if they have it.
Patrick Mueller - http://muellerware.org/
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
« Return to Thread: debugging interfaces
| Free embeddable forum powered by Nabble | Forum Help |
