Improve performance of -profile by factor of 10

[deadalnix]

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.