Warning: Long & complicated story! (With a request at the end)

It seems 5.6.1 has a much better resolution than 5.8.0. Is that the bug for which you are searching?

It's not quite that simple. Time::HiRes v1.2 is a very old version I think which could explain your results. Later versions (circa. >= 1.53 ) have code which uses a high resolution performance counter to enhance the low resolution of the GetSystemTimeAsFileTime() api.

However, under some circumstances, the use of the high res timer doesn't seems to work correctly. For example:

On my system, doing it this way the resolution is around 70/80 uSeconds:

P:\test>perl -MTime::HiRes=time -wle"print time for 1 .. 10"
1118814859.12534
1118814859.12551
1118814859.12558
1118814859.12566
1118814859.12573
1118814859.1258
1118814859.12587
1118814859.12594
1118814859.12602
1118814859.12609
[download]

but in the debugger, it suddenly becomes 31.25 milliseconds:

P:\test>perl -MTime::HiRes=time -de1
perldb: Must not source insecure rcfile ./perldb.ini.
        You or the superuser must be the owner, and it must not
        be writable by anyone but its owner.

Loading DB routines from perl5db.pl version 1.25
Editor support available.

Enter h or `h h' for help, or `perldoc perldebug' for more help.

main::(-e:1):   1
  DB<1> print time . $/ for 1 .. 20;;
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.6875
1118815107.71875
1118815107.71875
1118815107.71875
1118815107.71875
1118815107.71875
1118815107.71875
1118815107.71875
1118815107.73438

  DB<2>
[download]

which is strange enough, but it gets stranger. I saw spurperl's comment in Re^2: Microseconds in Per regarding Time::HiRes resolution on Win32 and it reminded me of a similar effect I pursued a while ago after reading Unique filenames with Time::HiRes which lead to Re^4: Perl -de1 weirdness..

I was on a different machine/version of the OS back then, and when I tried to trackdown the problem, I couldn't reproduce it outside the debugger. Whilst I did raise a mention on p5p, a bug in a timer that only occurs inside the debugger isn't really critical.

However, and this is where it gets really strange, the other day when I read spurperl's comment, I ran the above test, and I was getting the 31.25 millsecond resolution outside of the debugger! Last night I decided to try and track it down again, and I ran some code using Win32::API to access the performance counter directly. Twiddled around a bit and then tried the test above again, and suddenly, the I was getting the 70/80 microsecond resolution outside of the debugger. I didn't install anything new.

Puzzled, I eventually tried rebooting to see what if any difference that made and it made none at all. I now have the high resolution timer outside of the debugger and nothing I have tried reverts me to the low res situation outside of the debugger.

Great you might say, but this is where I was on my old machine. I had the low-res timer always. Played with calling the performance counter, suddenly got the high res results and could find no way to revert outside of the debugger!

My feeling is that Windows is caching some state somewhere and that the calls inside Time::HiRes.xs are not triggering the enablement of the performance counter on their own. But once the performance counter has been enabled, Time::HiRes is able to use it from that point on. How/why that would be so I cannot imagine at this stage.

So, what I need is someone who has Time::HiRes v 1.53 or greater that is getting low-res results. I am not sure whether the Perl version is relevant or not yet. PodMaster showed that high resolution results are possible on every build.

If I can find someone with T::H >1.53 getting low-res results, then I will ask then to run the piece of Win32::API code that appeared to make the difference on my machine and see if it has the same enabling effect for them.

Is there any chance of you upgrading to T::H > 1.53 in your 5.8.x install?

If you cannot find a PPM, I could always email you the files from here.