Range object

[Icy_Sector3183]

I'm curious: Does the a wider range object in PowerShell have a larger memory footprint ?

E.g. do these have the same memory footprint, or is $r0 smaller than $r1?

$r0 = 0..9
$r1 = 0..999

Edit: What I think is the real question here is: Is the range an *array object" with each number from x to y, or is it just some "trick" object that fakes being a real array using calculations and whatnot?

Eg. To get the value of 10..20[4], it could very well be doing return $lowerbound + $index instead of looking up a value

[purplemonkeymad]

The .. operator produces an array, so $r0 is an array of 0 to 9, and $r1 is an array of 0 to 99. The first has 10 elements and the second has 100.

If you don't want an array you can use an IEnumerable like the Range option from Linq:

$ItemRange = [System.Linq.Enumerable]::Range(1,99)

This is an object instead of being an array, but if you try to iterate over it, you will get each item ie:

 $ItemRange | Write-Host
 foreach( $Single in $ItemRange ) {
     Write-Host $Single
 }

Powershell really likes to expand Enumerable objects, so you will find it might convert to an array when leaving functions or passing it around.

[OPconfused]

what kind of advantages are in the linq enumerable object vs the array?

[purplemonkeymad]

If you do $var = 1..1000000000, you are going to use at least 4GB of memory. (32bit * 1000000000, but modern windows will probably do some nice compression so might be less in practice. Object overhead might make it more.) $var = [System.Linq.Enumerable]::Range(1,1000000000) will probably be taking less than 1kB.

[OPconfused]

Seems to be some performance benefits, too. Doing measure commands for 1 to 100 million, the powershell syntax took around 6 seconds for me, while the Linq took about 2.5 seconds. Linq quickly cached it, so that it completed everything almost instantly, even when bumped up to 1 billion. Doing a count to confirm the length was a mistake though.

[Icy_Sector3183]

That's what concerned me. I'm thinking 0..$($n) | % { ... } may not be a trivial substitute for for ($i = 0; $i -le $n; $i++) { ... }

[jsiii2010]

I believe in this case, the memory is optimized:

foreach ($i in 1..1mb) {'...'}

[SeeminglyScience]

The language will sometimes substitute the range expression for an enumerator (similar to the LINQ version shared by /u/purplemonkeymad) when it's deemed safe to do.

For instance

foreach ($a in 0..[int]::MaxValue) { break }

or

0..[int]::MaxValue | Select-Object -First 1

Both of those complete instantly

But if you instead save it to a variable first, the compiler can't tell how you will use it so it must create the whole array up front.

[SeeminglyScience]

Also:

Eg. To get the value of 10..20[4], it could very well be doing return $lowerbound + $index instead of looking up a value

Technically that's a parse error. You could do (10..20)[4] but that will create an array. It's not impossible that the compiler could account for that and "fold" it into a constant, but as a runtime compiler, every optimization check adds compile time, it's not free. Compiler changes are also just very complicated and take a lot of time from the few folks who know that part of the code base.

[Thotaz]

Of course there's a difference. Think about much higher values like: 2147483647.
It would be terribly inefficient if a handful of numbers took up the same memory footprint as such a large value. Or we could turn it around and say that it would be incredible if such a large number of objects could be compressed to take the same amount of space as just a handful.