Hite, Christopher wrote:

I'm in the process of writing a logging library and I noticed that each call to print out ptime took about ~50us. Even just printing out the duration time_of_day cost ~20us.

I'm using boost1.43 with g++ (GCC) 4.4.3 g++ -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -DNDEBUG

I was able to do the same thing for <1us not using stream ops (see code below).

Does anyone care to optimize this stuff? I'm considering specializing my own boost::date_time::ostream_time_duration_formatter to override to slow impl.

You should do this for your application -- everyone that asks me about high performance i/o with date time, I suggest they write their own functions because 1) it can typically be less general that what the library provides and 2) it's a minimal investment in time. Note that the first call to operator<< is going to incur a particularly high cost due to construction of facets under the hood.

template<typename int_t> void printDecimal(int_t d,int places,char* out){ int_t rest=d; for(int i=0;i

void printDuration(const boost::posix_time::time_duration& d,char* out){ int64_t ticks=d.ticks(); int64_t us=ticks%1000000; int64_t r1=ticks/1000000; int64_t s=r1%60; int64_t r2=r1/60; int64_t m=r2%60; int64_t h=r2/60; printDecimal(h,2,out); out[2]=':'; printDecimal(m,2,out+3); out[5]=':'; printDecimal(s,2,out+6); out[8]='.'; printDecimal(us,6,out+9); }

..

char buf[32]; printDuration(pt.time_of_day(),buf); std::cout<< buf <<" -\n"; // <1us

//std::cout<< pt.time_of_day() <<" -\n"; // ~15us

A perfect demonstration of my point -- this works great for a narrow stream with standard delimiters in a conventional duration format -- not so well for a wide stream with an arbitrary format string -- for example: BTW, I wouldn't be opposed to including a set of high performance functions in the library for those with this sort of application -- the real problem is getting folks to agree on a format to do this for (variations on iso format come to mind, though). Overall though, I really don't have the time or inclination to produce these at the moment. Jeff