Boost logo

Boost :

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-02-14 11:45:45


On Sun, 13 Feb 2005 19:42:18 -0500, christopher diggins
<cdiggins_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk