On Sun, 13 Feb 2005 19:42:18 -0500, christopher diggins <cdiggins@videotron.ca> wrote:
Basically, I'm looking for the ability to use a single instance of a profiler to collect stats for number of operations each of which are too brief to profile on their own, but when taken in aggregate you get meaningful data.
Does this make sense?
Actually I am a little confused, sorry. If the operation is too brief, do you mean it underflows? An aggregate which includes even a single underflow would be inaccurate, if that is what you intend to do. However, I am probably just confused.
Basically I want to keep a counter + timer running until the timer has reached some statistically valid value so I can divide timer / counter and get an average time-per-operation. I don't plan to start and stop the timer for each call, but keep it running until I've collected enough data. Here's an f'rinstance using boost::timer: size_t iterations = 0; boost::timer t; while (t.elapsed () < 1.0) { size_t i; for (i = 0; i < 100000; ++i) { do_some_fast_call (); } iterations += i; } double elapsed = t.elapsed (); std::cout << "do_some_fast_call: " << iterations << " calls in " << elapsed << " seconds: " << std::fixed << (iterations / elapsed) << " calls/sec, " << std::fixed << (elapsed / iterations) << " sec/call" << std::endl; I realize this collects some overhead due to the while/for loops, but the bulk of the processing should be do_some_fast_call. With the profiler, I can't do this "natively". If I add a profiler inside my 'for' loop, I will get underflows on each iteration (and I'll need to disable logging to keep the default IO from overwhelming my timings). If I use a profiler outside the loop, it will only report a single iteration, not the many tens/hundreds of thousands that actually happened. -- Caleb Epstein caleb dot epstein at gmail dot com