Re^2: does a hash element as a loop parameter cause significant slowdown?

> for my $c (1..$n1) {

> The list 1..$n1 is created in memory and then iterated over so $n1 is only evaluated once.

Nitpick:

you are right that $n1 is only evaluated once, but only old versions "created" the whole "list in memory".

This was optimized away ages ago to allow $a..$b to act like an iterator. Maybe 5.10ish?

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)

Wikisyntax for the Monastery}

Comment on Re^2: does a hash element as a loop parameter cause significant slowdown? Select or Download Code

Replies are listed 'Best First'.
Re^3: does a hash element as a loop parameter cause significant slowdown? by pryrt (Abbot) on Sep 09, 2023 at 00:00 UTC
Maybe 5.10ish? I checked perldoc.perl.org's 5.10 docs: it still had the "but older versions" comment. So I checked 5.005's docs: it still had the "but older versions" comment. So if perldoc.perl.org's copies of the docs are accurate, it was documenting the list-in-memory behavior as "old" even at 5.005! /me guesses he needs to get over his aversion to large ranges in foreach loops ;-)	[reply]
Re^4: does a hash element as a loop parameter cause significant slowdown? by LanX (Saint) on Sep 09, 2023 at 12:19 UTC
Yeah ... I already noticed this, but gave up searching the deltas because I started in the 5.8 era and remember being told about the "problem" But now I found it in the delta of 5.005 > foreach (1..1000000) is now optimized into a counting loop. It does not try to allocate a 1000000-size list anymore. It's the oldest available delta, which probably means only Perl4 had the issue. Cheers Rolf _{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :) Wikisyntax for the Monastery}	[reply]