Improve performance of -profile by factor of 10

[Vladimir Panteleev]

On Tuesday, 26 March 2013 at 07:45:34 UTC, Walter Bright wrote:
> On 3/25/2013 10:16 PM, deadalnix wrote:
>> 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 difficulty with that is when the app is posting 
> data to the profiling thread faster than the latter can process 
> it.

That's not how polling profilers work.

Polling profilers do not run alien code in the programs' thread. 
Thus, the program thread is not posting anything to the profiling 
thread.

I'm repeating myself, but: they work by having the profiler 
thread/process periodically pause the program thread, record its 
state, resume it, then analyze/store the collected data, and 
sleep a bit before taking another sample.

Even when the overhead of a polling profiler is higher, it has 
the qualifying difference in that the performance overhead does 
not skew the execution times of particular parts of a program as 
much as an instrumenting profiler. That is, while an 
instrumenting profiler makes some parts of the program much 
slower than others, a polling profiler should make the whole 
program about equally slower.