Improve performance of -profile by factor of 10

[Vladimir Panteleev]

On Friday, 22 March 2013 at 22:39:56 UTC, Walter Bright wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=9787
>
> This can be a fun little project, with a nice payoff. Any 
> takers?

This is a bit off-topic, but:

A polling profiler would be more precise and efficient than an 
instrumenting profiler.

A polling profiler simply periodically pauses the program thread, 
records its state, and resumes it. The advantage is that 
execution times of small functions are not skewed by the overhead 
added by instrumentation. A polling profiler runs mostly in its 
own thread, so it has a smaller impart on the main program 
thread. A polling profiler is also capable of measuring 
performance down to a CPU-instruction level.

The disadvantages of a polling profiler are:
1. The program must run for a considerable amount of time, so the 
profiler gathers enough samples to build a good picture of the 
program's performance;
2. As a consequence of the above, functions that execute quickly 
/ are called relatively rarely may not appear in the profiler's 
output at all;
3. Stack frames must be enabled, to be able to collect call 
stacks.

On Windows, I've had good success with compiling D programs with 
-g, converting their debug information using cv2pdb[1], then 
profiling them using Very Sleepy - I have a fork of it with some 
enhancements[2].

  [1]: http://dsource.org/projects/cv2pdb
  [2]: http://blog.thecybershadow.net/2013/01/11/very-sleepy-fork/