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:
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.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit