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
"Well done is better than well said." - Benjamin Franklin
In reply to Re: Special case mktime: semi-sequential access
by flexvault
in thread Special case mktime: semi-sequential access
by not_japh
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |