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.
[download]

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 :(