[snowhare]$ ./hires-time.pl
1133389582245150
1133389582245151
[snowhare]$ ./hires-time.pl
113338958348908
113338958348909
[snowhare]$ ./hires-time.pl
1133389583585585
1133389583585586
[snowhare]$ ./hires-time.pl
1133389584217773
1133389584217774
[snowhare]$ ./hires-time.pl
1133389584827558
1133389584827559
[snowhare]$ ./hires-time.pl
1133389585762938
1133389585762939
[snowhare]$ ./hires-time.pl
1133389586273604
1133389586273605
[snowhare]$ ./hires-time.pl
1133389586920152
1133389586920152
[snowhare]$ ./hires-time.pl
1133389587601760
1133389587601761
[download]

If it was simply being cached, I would expect it to always give me 0 microsecond results - instead I get it perhaps one time in eight (which makes sense since the machine is doing a number of other things as well so I don't expect 100% repeatability in the runs' timing).

Unless you can spot something in Time::HiRes itself that would cause caching, I am inclined to view the numbers as correct. Regardless, it shows that Time::HiRes can produce identical timestamps when pushed hard on a fast machine (in this case a Linux box running perl 5.6.2.)

Nope. Looking at the code in HiRes.xs, I see nothing that would be caching it. On the contrary, the fact that the gettimeofday() maps directly to the system api on your system means that the path from Perl to XS to OS and back is almost a straight one:

void
gettimeofday()
        PREINIT:
        struct timeval Tp;
        PPCODE:
        int status;
        status = gettimeofday (&Tp, NULL);
        if (status == 0) {
             if (GIMME == G_ARRAY) {
                 EXTEND(sp, 2);
                 PUSHs(sv_2mortal(newSViv(Tp.tv_sec)));
                 PUSHs(sv_2mortal(newSViv(Tp.tv_usec)));
             } else {
                 EXTEND(sp, 1);
                 PUSHs(sv_2mortal(newSVnv(Tp.tv_sec + (Tp.tv_usec / 10
+00000.0))));
             }
        }
[download]

That combined with your using 5.6.2, which doesn't need to lookup thread contexts, means that the overhead of the transitions is truely minimal.

I have to sit corrected and chalk one up to linux here. Using Perl on a system which forms the core of it's built-ins architecture has distinct performance advantages.

What triggered the caching thing in my mind was your making both calls to gettimeofday() within the same statement. I have a built in suspicion of this that I realise now is a hangover from using some time-related calls in C. On at least two C compilers I've used in the past, the compiler would do a subexpression elimination on a pair of identical calls in the same statement with the result that you the same value both times. I was bitten by this in a rather expensive way once.

That is obviously not the case here, but old pain lives long in the memory.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I don't think so, I can see the same results with his code, and if I run it through strace I get

gettimeofday({1133398137, 976963}, NULL) = 0
read(3, "", 4096)                       = 0
close(3)                                = 0
gettimeofday({1133398137, 977352}, NULL) = 0
gettimeofday({1133398137, 977383}, NULL) = 0
gettimeofday({1133398137, 977417}, NULL) = 0
gettimeofday({1133398137, 977441}, NULL) = 0
write(1, "1133398137977417\n113339813797744"..., 341133398137977417
1133398137977441) = 34
[download]

So you can see that all the gettimeofday system calls are actually taking place and the values are being printed out. It's possible of course that this is an artifact of the tracing, and the value is cached otherwise, but that doesn't seem too likely.