Vice versa. Look at the Rate column — it shows the speed of the function! The more times a second the function is called, the faster it is :) So in this table (produced by the benchmark involving all three variants)
Rate interval HiRes::time buitin time()
interval 88470/s -- -53% -95%
HiRes::time 188363/s 113% -- -89%
buitin time() 1753092/s 1882% 831% --
builtin time() is 9 times faster than Time::HiRes::time, which is nearly 2 times faster than the weird variant with tv_interval!
Benchmark code is here:
s;;Just-me-not-h-Ni-m-P-Ni-lm-I-ar-O-Ni;;tr?IerONim-?HAcker ?d;print
| [reply] [Watch: Dir/Any] [d/l] [select] |
As long as we're all tweaking the heck out of our benchmarks... ;-)
What I've noticed is the number of calls to these functions are not all the same. In the 'interval' function, we are calling gettimeofday, constructing an anonymous array, calling tv_interval, and destroying the array. Only one of these are we actually interested in. Meanwhile, both of the other two cases, we're calling *time twice. A completely different set of comparisons. I also eliminated the overhead of returning floats, what little that should be.
So, I thought I'd throw this into the mix. Put all the initialisation up front. Then see what happens.
And the results?
Rate interval time hires
interval 685148/s -- -79% -80%
time 3340426/s 388% -- -2%
hires 3398163/s 396% 2% --
2% bonus to hires's time over the built-in time? I'll chalk that up to statistically insignificant, and call the two a tie. In fact, I ran it a second time and got it reversed:
Rate interval hires time
interval 971246/s -- -77% -78%
hires 4192706/s 332% -- -3%
time 4327848/s 346% 3% --
So, I'd say that the difference between interval and time is non-trivial. But even that operates fast enough that I'm not going to worry about it. | [reply] [Watch: Dir/Any] [d/l] [select] |