in reply to Re: Special case mktime: semi-sequential access
in thread Special case mktime: semi-sequential access

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

Weak machine:
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)
stronger machine:
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)
benchmark.t
#!/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 }, });

Replies are listed 'Best First'.
Re^3: Special case mktime: semi-sequential access
by RichardK (Parson) on Jul 01, 2013 at 12:40 UTC

    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.