From PerlOP:
In the current implementation, no temporary array is created when the range operator is used as the expression in foreach loops, but older versions of Perl might burn
a lot of memory when you write something like this:
Many of my efficiency habits formed back in 5.6/5.8 days, and I've never seen the need to change them.
One problem is that optimisation only kicks in in certain circumstances -- and I don't remember if I ever knew what they exactly were. I have a sneaking suspicion that in 32-bit perls, anything over 2**31 may have caused a list, but I haven't used a 32-bit perl for a decade, so I cannot check.
One example that bit me was the iterator moving outside the range of integers: 1 for 1e200 .. 1e200+1e6;;
[Range iterator outside integer range at (eval 10) line 1, <STDIN> lin
+e 2.
Easy enough to re-write that one, but not so much if the numbers come from outside or are generated.
The while/until loop approach handles anything 64-bit floats can, and (from) memory, is usually faster than postfix for even for integers; though that could have changed a lot since I last benchmarked it.
I like to program in a consistent way -- where it doesn't compromise performance to do so -- and tend to stick with patterns once I've established ones that work.
Eg. I still use '<:raw' as a matter of course, even though things changed and it was deprecated when they re-vamped PerlIO, and it was demonstrated that some other combination of pushing, popping and/or applying of layers was apparently faster. The whole thing just got too complex to remember and too convoluted to test.
The whole PerlIO thing was something of a debacle IMO; a vast amount of effort and change for something that 95% of Perl users have never used :(
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
|