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

Subject: [boost] [chrono/date] Performance goals and design summary
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-04 09:56:02

Hi,

After the discussion on other threads I would like to summarize some of 
my performances goals while refactoring the H.H chrono/date library, 
just to see if I was wrong and going on the bad direction:

 1. *Be able to build dates without validating them.*
 2. *I wanted the library to be as efficient as possible when the user
    uses constant objects or literals, no need to validate at runtime
    what has already been validated by the compiler*.
 3. *Possibility to reassign a date if the parameters represent a valid
    date.*
 4. *No a single date class is better than the others on all the
    algorithms*.
 5. *No additional meta-data in absolute dates so that you don't pay for
    the relative dates overhead when using absolute dates.*
 6. *The user must be able to get all the date related informations at
    once.*

Do you have other?

The way I have managed with these goals is

 1. *P*rovide an unchecked date construction interface with a no_check_t
    parameter and an is_valid() function.
 2. *T*he date parts day/month/year need to be validated or constructed
    with no_check_t.
 3. dt.set_if_valid(year, month, day)
 4. Define the Date requirements all the dates must satisfy, implement
    ymd_date, days_date, ...
 5. Separate the absolute and the relative Date requirements into two
    Date concepts AbsoluteDate and RelativeDate. Provide at least a
    relative_date class based on the ymd representation.
 6. Conversion between different concrete date classe.

H.H approach respond to these goals in a different way

 1. date and its parts provide constructors that are not validated, the
    validation is provided by factories as operator/.
 2. I don't think this can be achieved when the date must be validated.
 3. No problem, this could be added to H.H approach (at least for its
    YMD date).
 4. Same approach. H.H proposes two classes chrono::day_point (only
    unchecked) and YMD date.
 5. I'm not sure the date YMD class doesn't include meta data (Howard
    could you clarify your point here)
 6. same approach.

I have some questions for followed by my personal answer;

  * *Do you see some unnecessary goals, in particular, is the goal
    2**necessary?*  IMO, yes. Not providing an interface that allows
    compiler optimizations is against the C++ philosophy. The question
    is as always, what would be the gain? In the best case we could
    avoid 6 comparisons.
  * *Does the introduction of no_check to achieve goal 1 and 2 results
    in a uglier date interface?* IMO, yes, but I don't know how to
    achieve goal 2 without.
  * *Should a concrete date class provide just the functionalities it is
    able to do efficiently?* IMO, yes. This would prevent the user of
    non efficient services (Note that my current design doesn't follows
    this)
  * *Do we need a Date concept that a concrete date must model**?* IMO,
    yes. SO we need two levels, level one provides the most efficient
    service, level two provides an homogeneous interface.
  * *Do we need to make the separation between absolute and relative
    dates?* IMO, yes. While relative dates are powerful they incur on
    unwanted overhead when absolute dates are needed.

Best,
Vicente