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/
