On Tuesday, 26 March 2013 at 05:01:03 UTC, Walter Bright wrote:
On 3/25/2013 8:01 PM, Vladimir Panteleev wrote:
On Tuesday, 26 March 2013 at 02:57:07 UTC, Walter Bright wrote:
While you can get the caller (after all, debuggers do it), it
can be
arbitrarily costly (in terms of execution speed) to do so,
which can negate
many of the advantages of a probing profiler.
What? You just read the value EBP is pointing at, or something
like that.
Walking the call stack is basically walking a linked list.
If only it were that simple.
1. many stack frames do not have an EBP
2. the stack frames on Win64 require doing a bunch of table
searches to figure out - they don't use EBP
3. even when you find the return address, then it's a costly
process to figure out what function that address belongs in
You can still stop the thread, gather the data you are interested
in, and doing the whole process while resuming the application,
which leverage concurrency.
The obvious advantage is that you don't measure the profiler's
performance in addition to your app's.
BTW, I want to raise issue with fibers. We should report 2 stacks
: the stack of function calls, and the stack of fiber calls.
