in reply to Re: Special case mktime: semi-sequential access
in thread Special case mktime: semi-sequential access
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)
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^3: Special case mktime: semi-sequential access
by flexvault (Monsignor) on Jul 01, 2013 at 13:10 UTC |