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.
