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

From: Sérgio Vale e Pace (svpace.forum_at_[hidden])
Date: 2005-02-10 15:20:49

On Thu, 10 Feb 2005 14:12:16 -0500, Gennadiy Rozental
<gennadiy.rozental_at_[hidden]> wrote:
> > > 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?

why to do it? Is there any issues in using macros int this specific
case? it´s easy to implement, provides the all or nothing inclusion
control we are looking for, and most programmers will easily
understand the code.
 
> > > 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 do agree with you about the fact that good PBD  should provide
orthogonal policies, but the fundamental use for PBD is to delay
implementation details to when they are needed, allowing easy to
create and mantain yet flexible and extensible implementation. IMHO
two policies (one for timer and one for logging) is more than enough
for a profilling tool, how to colect data, when to report it how to
report it, what estatistical analisys should be used are all policies
for the logging policy, not the profiler. Some simple reports like
"foo() - 50% - 10 ms" are usualy more than enough for simple tasks.
Let´s save the big guns for the big tasks ;)

> > 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.

idem above

> >
> > > 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.

but usually simplicity make´s it less wrong, IMHO.
 
> > > 2. Stats Policy
<snip> 

same as before KISS principle

<snip> 
> > > 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.
> 

It doesn´t have to be "good enough" as long as it is able ot evolve to
become good enough, one of the points in reusing software is to be
able to enhance several components by enhancing just one of then.
Interfaces is importante, implementation is secondary. As long as
there something tha are able to report how many seconds elapsed from
moment A to moment B it really don´t matter how it´s done internally.

Sérgio