Re: Special case mktime: semi-sequential access

[flexvault]

Welcome not_japh,

The hypothesis appears confirmed by some benchmarking of 1e7 (sequential!) dates:

Originally I looked at this and thought that this is a job for 'use Memoize;', but then I thought if the inputs are sequential, maybe it's a real time program and once a second changes, you never go back. This is an alternate approach with-out the calculations.

sub new_caching_mktime
{   my ($sec, $min, $hour, $day, $mon, $year) = @_;
    my $time;
    my $curinput = "$sec:$min:$hour:$day:$mon:$year";
    if ( $curinput eq $saveinput )
    {    $time = $savetime;
    }
    else
    {
        $time = POSIX::mktime( $sec, $min, $hour, $day, $mon, $year );
        $savetime = $time; $saveinput = $curinput;
    }
    return $time;
}

Obviously '$savetime' and '$saveinput' needs to be defined for global use.

On most modern computers you can call a small subroutine like this hundreds of thousands times per second, and each time the cached time will be used.

Personally, what I like is that you're using caching to improve the performance of the script. That technique will help you lots of times in the future.

Good Luck...Ed

[not_japh]

Your version is more compact and satisfying, but it's slower because it missed the point (probably because I didn't state it!). Mine is not not memoizing, so perhaps calling it caching_* was a poor choice.

You can do math to avoid calling mktime not just in the cases it's seen, but also for other times within the same day. The math is simply this: if you know any epoch time in some day of interest, and you know what HMS that maps to, you can do two multiplies and a few adds to find a new epoch for a new HMS in that same day.

Benchmark: timing 5 iterations of FastMktime::caching_mktime, FastMkti
+me::new_caching_mktime, POSIX::mktime, TIME::Local::timegm_nocheck...
FastMktime::caching_mktime: 65 wallclock secs (64.36 usr +  0.02 sys =
+ 64.38 CPU) @  0.08/s (n=5)
FastMktime::new_caching_mktime: 220 wallclock secs (157.44 usr + 62.10
+ sys = 219.54 CPU) @  0.02/s (n=5)
POSIX::mktime: 122 wallclock secs (60.43 usr + 60.86 sys = 121.29 CPU)
+ @  0.04/s (n=5)
TIME::Local::timegm_nocheck: 141 wallclock secs (140.86 usr +  0.30 sy
+s = 141.16 CPU) @  0.04/s (n=5)

[flexvault]

not_japh,

Now that you explained why you are using the calculations, you method makes good sense. The previous suggestion of using midnight also may improve the performance a little more. Your call.

Regards...Ed

[Dallaylaen]

To me it looks like a multiplication by 60 is simple enough and doesn't deserve caching. On the other hand, calculating date is tricky as it involves legacy code dating back to the Roman empire. So the OP approach definitely has some grounds. I wonder what benchmark would say though.

Besides, a log file is not always sequential if several applications run at once and buffering is involved.

[not_japh]

Sequential not necessary. Just within the same day is enough to avoid the date calculations by doing the time ones yourself.