Yeah there might be some swapping but no direct files. I converted the benchmark (code below) to use timethese(5) to do some repeating.

Benchmark: timing 5 iterations of FastMktime::caching_mktime, POSIX::m
+ktime, TIME::Local::timegm_nocheck...
FastMktime::caching_mktime: 120 wallclock secs (120.21 usr +  0.05 sys
+ = 120.26 CPU) @  0.04/s (n=5)
POSIX::mktime: 360 wallclock secs (165.42 usr + 193.81 sys = 359.23 CP
+U) @  0.01/s (n=5)
TIME::Local::timegm_nocheck: 293 wallclock secs (292.72 usr +  0.14 sy
+s = 292.86 CPU) @  0.02/s (n=5)
[download]

Benchmark: timing 5 iterations of FastMktime::caching_mktime, POSIX::m
+ktime, TIME::Local::timegm_nocheck...
FastMktime::caching_mktime: 65 wallclock secs (64.77 usr +  0.02 sys =
+ 64.79 CPU) @  0.08/s (n=5)
POSIX::mktime: 118 wallclock secs (58.16 usr + 60.47 sys = 118.63 CPU)
+ @  0.04/s (n=5)
TIME::Local::timegm_nocheck: 143 wallclock secs (143.07 usr +  0.54 sy
+s = 143.61 CPU) @  0.03/s (n=5)
[download]

#!/usr/bin/perl

use FastMktime;
use Benchmark qw(:all);
use POSIX qw(mktime);
use Time::Local;

my $sstart = time;
my $sstop  = $sstart + 1e7;
my @dates;

# Stuff 1e7 sequential datestamps into an array. 
for (my $s=$sstart; $s<$sstop; $s++) {
  push(@dates, [ (gmtime $s)[0..5] ]);
}

my $tmp;
my $results = timethese(1, {
    'POSIX::mktime' => sub { $tmp = POSIX::mktime(@$_) for @dates },
    'TIME::Local::timegm_nocheck' => sub { $tmp = Time::Local::timegm_
+nocheck(@$_) for @dates },
    'FastMktime::caching_mktime' => sub { $tmp = FastMktime::caching_m
+ktime(@$_) for @dates },
});
[download]

Yep, that's very interesting, I get similar sorts of results here but mktime only takes 33 seconds. my machine isn't that new so I don't know why there such a big difference. I'm running perl v5.16 on 64 bit Linux.

mktime seems to stat /etc/localtime every time so that's where the system time is coming from, it's odd that it isn't cached, but I don't think I want to delve into the depths of the posix library to find out more ;).

I guess you could tweak your code a little bit, if you're after every last cycle :-

A valid $day can never be zero so there no point testing if $mk_day > 0, $mk_day == $day is enough

and if you create your times for midnight i.e.  $time = POSIX::mktime(0, 0, 0, $day, $mon, $year); then you can drop $mk_hms and save yourself one whole subtraction :)

RichardK,

Good point about using midnight of the specific day, and you could use a hash for saving(caching) each different date. That way you only need to call 'POSIX::mktime' once per day.

Interesting!

Regards...Ed

"Well done is better than well said." - Benjamin Franklin

Good observation about using midnight. Done. The mk_day was to detect a startup condition, but that can go too. The only remaining case is handling mktime(0,0,0,0,0,0) which should return undef.