On Thu, Aug 13, 2009 at 6:49 AM, Patrick Mueller<
pmuellr@...> wrote:
> 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.
A good list. Another is to accumulate traces for post-mortem
debugging, as in
<
http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html>,
<
http://wiki.erights.org/wiki/Causeway>. This becomes especially
important for debugging systems consisting of multiple clients and
servers. From a performance perspective, this is probably in the same
category as performance tools.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
