[boost] Re: Re: Latest version of the profiler

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-02-10 14:12:16

> > Why didn't you go with MACRO-less solution?
>
> Because it is a non-standard way of doing things. The majority of boost
> libraries use macros to control compilation.

So what? I couldn't comment on the case where boost libraries use macros,
but if there is a way to do without, why not?

> > 1. Logging Policy
> >
> > This policy supposed to be responsible for *how* you do logging (not
what
> > or
> > when).
>
> That seem unnecessarily inflexible. How can you determine in advance what
> should be logged and when it should be logged? Also, why do you say
> "supposed to"? What are the specific reasons why the logging policy design
> is flawed.

I couldn't. But most importantly I shouldn't. PBD is not about providing
single logging policy that do everything related to logging. PBD is about
providing orthogonal (independent) policies each one with specific
responsibilities. In this case Logging Policy responsibility is to define
"how to do logging". Collection Policy defines what to log and Reporting
policy defines when to log. Each one independent and easily substituted. If
you policy responsible for everything and you component is just hollow
forwarder, then such component doesn't bring any value and in most cases it
would be easier to write custom component itself then custom policy.
Yes it is not simple to design PB component that both flexible to cover most
important cases and is not hollow so that it has real value. With proper
design every policy has specific responsibilities with specific interfaces
related to these responsibilities, while you component orchestrates policies
interactions.

> I give the option to the user through the policy. I could separate the
> logging policy into three separate policies: when_to_log_policy,
> how_to_log_policy, what_to_log_policy. But it is to simple to warrant this
> extra refactoring IMO.

You already have other policies responcible for these tasks.

>
> > Accordingly it shouldn't be event driven. It should be ... feature
> > driven:
> > log_start(...), log_finish(...) e.t.c. I don't really understand how you
> > intend to use your current interface.
>
> I don't see how this confusion could arise given the simplicity of the
> design. Could you ask a more specific question?

Simplicity of design doesn't make it correct.

> > 2. Stats Policy
> > From you docs (emphasis is mine): "The stats policy is responsible for
> > collecting *and* reporting statistics". Did you notice 'and'? You still
> > trying to put two eggs into same basket.
>
> The collecting and reporting of statistics is inextricably linked. You can
> only report stats that you have collected. I do not see how you could
> separate the two.

Collecting is responsible for WHAT to collect.
Reporting is responsible for WHEN to report.

I do not see why would I want to unit them into single concept.

> > What if you want 2 different
> > profilers, both scoped, but first measure wall-clock time,
> > second measure
> > process time?
>
> That is beyond the scope of the library. I can not imagine a profiling
tool
> which would want to measure wall clock time. The profiler library measures
> time durations only.

There are different kinds of time duration and different ways to measure it.
Wall clock time is as good anything else. But even with process time, I may
want to measure clocks or user/system time separately.

> > 3. Timer concept
> > I am not sure that boost::timer interface present the best abstraction
for
> > Timer concept.
>
> However it is what we have to build off of. There was a lot of work that
> went into it, and I am confident in the design decisions that were made. I
> also like the simplicity of it.

Where did you get your confidence from? Does your design passed through
challenges presented in variety of possible profilers out there? Simplicity
is good until it cause inflexibility.

> > Among other things I believe you also need time_type (long,
> > long long, int64_t, timeval e.t.c). Also using double for elapsed in
> > general
> > may not be desirable also.
>
> I agree that this would make it more powerful, however it would also give
a
> false sense of security w.r.t the robustness of the tool. I don't want to
> spend an inordinate amount of time dealing with the quirkiness of timers.
It
> is a very complex subject, and virtually impossible to do both portably
and
> correctly. I believe that what was good enough for boost::timer, is good
> enough for boost::profiler.

The thing is that boost::timer is not good enough for many non-trivial
profiling tasks (and it was discussed here on ML many times). Overflow is
one of the major issues for example. So without larger time type you
couldn't get around it's deficiencies.
  I do understand that you do not want spend time/effort more on this, but
don't expect us(me) to blindly agree to what you have right now.

Regards,
Gennadiy