Re: [boost] [chrono/date] Performance goals and design summary

Subject: Re: [boost] [chrono/date] Performance goals and design summary
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-05 18:07:18

On May 5, 2013, at 2:45 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> However if I take your days_date year() example the user must know that on order to get the year it is better to go through  a ordinal_date instead of a ymd_date.
> I don't know how yet, but as a end-user I would like to get this 20% gain in a less intrusive way.
> 
> Maybe days_date shouldn't provide a year() function but can provide another function that will not ensure the minimal performances.
> 
>    year calculate_year();
> 
> I don't know what others think, but I would prefer to type
> 
>  dd.calculate_year()
> 
> than
> 
>  ordinal_date(dt).year()
> 
> The use of calculate_ could be a sympthom of possible deficiencies of the algorithm.

We're accustomed to converting among time_t, tm, etc. to get what we need. I don't find the explicit conversion necessarily a problem. However, the general idea that we should omit inefficient member functions so users don't pessimize their code smacks of nannyism.

Profiling is the proper way to discover overhead in a program. If using day() or month() is inefficient, but has an insignificant effect on the overall program, then the user wins through ease of use. If the overhead is an issue, then the user can make the type conversion or add caching, or even do something algorithmically different, based upon the context, and might do better than any library magic you devise.

IOW, I'm favoring similar interfaces with differing complexity requirements, leaving optimization to the user.

___
Rob

(Sent from my portable computation engine)