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.