Re^3: Special case mktime: semi-sequential access

[RichardK]

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 :)

[flexvault]

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

[not_japh]

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.