Re: Re: Time::Hires Granularity

Thanks for the reply, maybe I was unclear...
The issue is not the number of prints. As I said I am getting about 700 prints of the same time, and then the next set of lines is time+0.06
I am confused as to why the routine can loop 700 times without updating the 'time' variable. Is is that the system is only capable of receiving a request for the time information every .06 seconds? I was hoping that the increment would be smaller (1/100th of a second would be fine). Is this a Windows issue, or, less likely, a code problem; if so, are there any sensible workarounds that anyone could suggest.
Cheers :-)

Comment on Re: Re: Time::Hires Granularity

Replies are listed 'Best First'.
Re: Re: Re: Time::Hires Granularity by bart (Canon) on Dec 04, 2003 at 22:25 UTC
As I said I am getting about 700 prints of the same time, and then the next set of lines is time+0.06 Actually, it should be closer to 0.055. Windows' internal click gets updated 18 times a second, or once every 55ms, via a timer interrupt. The API call GetTickCount() exhibits the same behaviour as you describe here. The docs for this API call mention: It is limited to the resolution of the system timer. So yes, even though I haven't seen any evidence that the two phenomenons are indeed related, their symptoms are so strikingly alike, that I'm quite convinced they share the same origin. So yes, it's a Windows Thing™. Update: I don't mean to say it cannot be fixed/patched, only that this is behaviour you'll typically only see in Windows, for this particular case.	[reply]
Re: Re: Re: Re: Time::Hires Granularity by BrowserUk (Patriarch) on Dec 04, 2003 at 22:58 UTC
So yes, it's a Windows Thingâ„¢. I think that is a little unfair. With the appropriate patches to Time::HiRes, it's resolution could be improved markedly. Leastwise for elapsed timing if not easily for absolute timing. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail Hooray! Wanted!	[reply]