I am probably missing something, but have you tried boost::date_time library?
boost::posix_time::ptime now = boost::posix_time::microsec_clock::local_time(); How does it compare in terms of efficiency? -- Norman > -----Original Message----- > From: Rush Manbert [mailto:[email protected]] > Sent: 27 May 2009 22:15 > To: [email protected] > Subject: Windows Timers - Seeking Opinions > > I posted this to the dev list, but I know that there are people who > probably only read this list that might have an interest in the > subject, so I'm posting it here too. > > Hi all, > > I have moved my Boostified Thrift C++ library code to my Windows XP > box and I now have the concurrency test running. It's slow as > anything, but I'm hoping that's because it's a 5 year old single CPU > Athlon 64. I know my new code is as fast as the current library on the > Mac. > > It turned out that one of the biggest headaches in Windows was the > system timer. I read a lot of Internet posts and went through three > implementations before getting one that is acceptable. There are, > however, tradeoffs and I was hoping that interested and knowledgeable > parties here might offer some opinions/insight. > > The Windows system timer is just basically crappy. The millisecond > epoch time clock provided by the C runtime library really updates at > about 60 hz, and they just change it to whatever the current > millisecond count should be. And when the system gets busy (lots of > threads) the update becomes very haphazard. > > The highest precision timer is the performance counter, which runs at > some frequency that is subdivided off the CPU clock or a peripheral > clack. On my system it runs at about 3.5 Megahertz, so it's plenty > fast. But it has its own problems. From what I have read, it can slow > down because of power save modes on the computers, and each core in a > multi core machine has its own counter. This means that if your > process gets moved between cores, the timer reading can change, and it > can possibly appear to go backward. I believe we could get around that > by remembering the last time value that was returned, and just not > letting time go backward. For the purposes of Thrift, I think that > would work. I don't know how to handle it if the timer can really slow > down, though. > > The last one that I tried, after reading about the nasties in the > performance counter, is timeGetTime(). This gives the count of > milliseconds since Windows was started. As long as you calibrate it > against the epoch time on the first access (same thing has to be done > if you use the performance counter), it seems to give good results > with millisecond accuracy. However, in order to use it you must link > against Winmm.lib/dll. This appears to be a safe choice, as the dll is > supplied with all Windows systems. > > So at this point, I'm planning to go with timeGetTime(), making it a > requirement that all Windows apps that use Thrift be linked against > Winmm.dll. Do I hear any well reasoned objections or alternatives? > > Thanks, > Rush
