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

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-10 15:08:06

----- Original Message ----- 
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, February 10, 2005 2:12 PM
Subject: [boost] Re: Re: Latest version of the profiler

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

This is too general. Please state a specific problem with the current code.

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

I would appraciate a specific use case which shows the failure of the 
current code, and how an alternative design specifically solves the problem.

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

I was talking about the Boost.Timer not my own design.

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

It is not a bad idea then to update the timer resolution. However, I find it 
strange that the expectations on the Profiler library would be greater than 
those placed on the Boost.Timer library.

Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org