I had tried Time::HiRes::clock(), but that gives the same resolution as times. So I thought that was a dead end.

However, I went back and read again. There are Time::HiRes::clock_gettime($which) and Time::HiRes::getres($which). Where the $which is the name of a POSIX high resolution timer. I confess I had assumed that this was wall-clock.

The POSIX timer CLOCK_REALTIME claims a resolution of 1E-9 on my machine. Hurrah :-) However, that is wall-clock. Boo :-(

The Time::HiRes hints that there may be other timers... so, I went digging in the POSIX documentation. I found CLOCK_PROCESS_CPUTIME_ID, which does what the name suggests, and also claims a resolution of 1E-9 on my machine. Hurrah !

Conclusion, yes: turns out that Time::HiRes is the answer -- thank you. To know that, however, you need to know that:

• there is a "clock" called CLOCK_PROCESS_CPUTIME_ID -- provided you have a POSIX compliant system, and _POSIX_CPUTIME is defined (which is discovered using getconf).
• that you use can import that name from Time::HiRes and use it with Time::HiRes::clock_gettime($which) and Time::HiRes::getres($which) to access the timer.
• there is also a "clock" called CLOCK_THREAD_CPUTIME_ID, which is available if _POSIX_THREAD_CPUTIME is defined.
So, for my purposes:

  use Time::HiRes qw(clock_gettime CLOCK_PROCESS_CPUTIME_ID) ;
  $start = clock_gettime(CLOCK_PROCESS_CPUTIME_ID) ; # replaces $start
+ = (times)[0]
  ...
  $end   = clock_gettime(CLOCK_PROCESS_CPUTIME_ID) ; # replaces $end  
+ = (times)[0]
[download]

is the trick -- which I note in case it's of use to anyone like me who knew nothing of it until today.

If you're on FreeBSD, you could use BSD::Process to measure elapsed kernel and userland time with microsecond precision.