Indeed.

BTW, I get the lower-resolution results even w/o the debugger (but I've got 5.6.0 here).

- tye        

Yes. I've got 5.6.1 that still has the version 1.43 of Time::HiRes that shipped with it, and that uses GetSystemTimeasFiletime() which is the normal 1/64 (1/18) of a second resolution.

The GetPerformanceCounter() code came in at 1.53 and was tweaked again in 1.59.

I think I found the code that causes it in Time/HiRes.xs:

/* If the performance counter delta drifts more than 0.5 seconds from 
+the
 * system time then we recalibrate to the system time.  This means we 
+may
 * move *backwards* in time! */

#define MAX_DIFF Const64(5000000)

static int
_gettimeofday(pTHX_ struct timeval *tp, void *not_used)
{
    dMY_CXT;

    unsigned __int64 ticks;
    FT_t ft;

    if (MY_CXT.run_count++) {
__int64 diff;
FT_t filtim;
GetSystemTimeAsFileTime(&filtim.ft_val);
        QueryPerformanceCounter((LARGE_INTEGER*)&ticks);
        ticks -= MY_CXT.base_ticks;
        ft.ft_i64 = MY_CXT.base_systime_as_filetime.ft_i64
                    + Const64(10000000) * (ticks / MY_CXT.tick_frequen
+cy)
                    +(Const64(10000000) * (ticks % MY_CXT.tick_frequen
+cy)) / MY_CXT.tick_frequency;
diff = ft.ft_i64 - MY_CXT.base_systime_as_filetime.ft_i64;
if (diff < -MAX_DIFF || diff > MAX_DIFF) {
     MY_CXT.base_ticks = ticks;
     ft.ft_i64 = filtim.ft_i64;
}
    }
    else {
        QueryPerformanceFrequency((LARGE_INTEGER*)&MY_CXT.tick_frequen
+cy);
        QueryPerformanceCounter((LARGE_INTEGER*)&MY_CXT.base_ticks);
        GetSystemTimeAsFileTime(&MY_CXT.base_systime_as_filetime.ft_va
+l);
        ft.ft_i64 = MY_CXT.base_systime_as_filetime.ft_i64;
    }

    /* seconds since epoch */
    tp->tv_sec = (long)((ft.ft_i64 - EPOCH_BIAS) / Const64(10000000));

    /* microseconds remaining */
    tp->tv_usec = (long)((ft.ft_i64 / Const64(10)) % Const64(1000000))
+;

    return 0;
}
[download]

The comment suggests that this is to sync the performance timer numbers to the System Clock times, and I think this bit

    if (MY_CXT.run_count++) {
[download]

is meant to ensure that the first part of the if/else is only entered once as MY_CXT.run_count isn't referenced any where else other than it's declaration. Basically an unsigned long 'first-time-only' flag.

That suggests that somehow running under the auspices of the debugger is causing that C struct flag field to be reset. Quite how or why that could or would happen there and not in normal code is beyond my understanding of how the internals work. Not that that is saying much as I (re)-discovered recently, but t'is most perplexing.

I guess it's time to turn it over to the internals guys?

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon