I benchmarked your code against mine, and for performance, my original 'UnPack' is faster on my hardware with debian linux and perl5.12.2.
case1 is mine, case2 is yours. I took out your test on the input since the input is CRC verified before calling 'UnPack'. I then modified my code to use 'for' instead of 'while' and using 'push' and now the results were only 2% faster.
This routine is called about 14 million times on a run of 100,000 inputs. The first time I profiled the program that this is part of, more than 50% of the time was spent in pack/unpack. I have done a lot of tweaking to get the performance. A year ago the 1st 100K run, I could only get 50 operations per second. Now on a 1,000K run, I get 1700 operations per second and pack/unpack is less than 10% of run time.
Benchmark: timing 500000 iterations of case1, case2... case1: 3 wallclock secs ( 3.76 usr + 0.00 sys = 3.76 CPU) @ 13 +2978.72/s (n=500000) case2: 4 wallclock secs ( 4.11 usr + 0.00 sys = 4.11 CPU) @ 12 +1654.50/s (n=500000) Rate case2 case1 case2 119332/s -- -9% case1 131234/s 10% --
This code was necessary to allow disk positioning on a 32 bit OS of 2**53 and 2**63 on 64 bit OS and still be network neutral. That also means I don't have to consider big/little endian problems. None of this would be necessary if pack/unpack had network neutral 64 bit integer that worked on both 32bit and 64bit hardware/OS.
Thank you
"Well done is better than well said." - Benjamin Franklin
In reply to Re^2: Force 'sub' return to be treated in list context?
by flexvault
in thread Force 'sub' return to be treated in list context?
by flexvault
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |