oneill1979 wrote:

We noticed recently that using a local_date_time in tight loops was several times faster than using a ptime object. As these are both based largerly on the same template code this was a surprise. It appears this is caused by the implementation of the operater+=/-= and was wondering if there was any justification for the difference or if this was just an oversight.

.\boost\date_time\local_time\local_date_time.hpp //! Local_date_time += time_duration local_date_time_base operator+=(const time_duration_type& td) { this->time_ = time_system_type::add_time_duration(this->time_,td); return *this; }

.\boost\date_time\time.hpp time_type operator+=(const time_duration_type& td) { time_ = (time_system::get_time_rep(date(), time_of_day() + td)); return time_type(time_); }

It looks like the ptime implementation is doing extra work to split the ptime into date and time_duration components and if it is changed to follow a similar pattern to that used in the local time the performance is then indistinguishable. time_type operator+=(const time_duration_type& td) { this->time_ = time_system::add_time_duration(this->time_, td); return time_type(time_); }

I can only think that maybe this was done to work around an issue and in which case should the same then be applied to the local time implementation?

The library can store ptime in one of the two ways: as a single 64-bit time duration or a pair of date and time duration (thus yielding a 96-bit tandem). The latter is available by defining BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG. I'm guessing, the code in time_base implementation is oriented to the extended 96-bit mode, while local_date_time does not make that assumption. So, the time_base code may perform better if BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG is defined. I may be wrong, though. Anyway, I think it's better create a Trac ticket for this issue.