Boost logo

Boost :

From: Philippe Mori (philippe_mori_at_[hidden])
Date: 2005-02-05 19:01:01


>
> The profiler that I am proposing would only measure a code block. This
> restriction is not too burdensome for my purposes, but I can not speak as
> to other people's unit tests. What is your view on this, generally and
> w.r.t to your current specific usage case?
>

Well, profiling associated to a block covers most case but definitively not
all cases. So for other cases, we need to be able to start or stop the
profiler
for a given counter.

Cases where blocks profiling are not enough include :

- Removing time elapsed in the user interface (say we display a message
box to the user).
- Profiling that should start in one function and end in another one.
- We might need to stop accumulating before the end of the scope in some
cases (for example, before displaying an error to the user).
- Some timing might be related to event handling or idle processing.
- We might want to deduce the time from an inner block to see the calling
overhead.

For most flexibility, we need automatic (RAII) and manual profiling
(explicit start and stop and increment).

Philippe


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