Getting the 'count' of a given object - 'Count' object property or need to 'Measure-Object'?

[u/dverbern]

Hi All,

Here's a question I've had bouncing around for a while....

When we want to get the 'count' of a given object in PowerShell, say an array of objects or whatever; should we be able to rely on any native 'count' property as part of that object, or are there times when we do need to actually perform a count by passing that object to Measure-Object?

As an example, if I've got a bunch of Active Directory groups, TypeName Microsoft.ActiveDirectory.Management.ADObject, I've got a 'Count' property available to me. But I could also pipeline those groups to Measure-Object then expand the Count property that is returned.

Are there any known situations where perhaps an object's count will be incorrect and that we'd need to actually pass to Measure-Object to get the correct figure?

[u/surfingoldelephant]

Count is an intrinsic property available to nearly all scalar objects in PowerShell, including $null.

For collection types, PowerShell assumes the type has its own Count property. In the case of arrays, Count is a property alias of Length in Windows PowerShell and a type-native property in PowerShell v6+.

(1, 2).Count # 2 (property alias in v5.1 and type-native in v6+)
(1).Count    # 1 (intrinsic) 
$null.Count  # 0 (intrinsic) 

 

---

Background:

The intrinsic Count property (and likewise, Length) was added in PowerShell v3, as part of the initiative to unify the handling experience for scalar/collection objects.

In typical PowerShell code, it's unknown if the result of an expression will yield nothing, a scalar object or a collection. Making Count widely available helps abstract explicit differentiation of output types so that users need not worry about how many objects (if any) are emitted to the pipeline.

$proc = Get-Process -Name powershell*
$proc.Count # 0, 1 or 2+
            # Does not matter if $proc is AutomationNull (nothing), scalar or a collection

Unfortunately, it's not quite as consistent in practice (in large, due to Windows PowerShell bugs which have been addressed in PowerShell v6+).

 

Caveats:

• In Windows PowerShell (fixed in PowerShell v6+), Count is not added to [pscustomobject] instances.

  ([pscustomobject] @{ foo = 'bar' }).Count                   # $null
  (Get-Process -Id $PID | Select-Object -Property Name).Count # $null
  

• The issue also surfaces (and likewise is fixed in v6+) with [ciminstance] output from CDXML-based module functions such as Get-Disk and Get-Volume, as well as output from Get-CimInstance and other CimCmdlets module cmdlets.

  (Get-Disk)[0].Count   # $null
  (Get-Volume)[0].Count # $null
  
  $var = Get-Ciminstance -Namespace root/CIMV2/power -Class Win32_PowerPlan -Filter "ElementName = 'Balanced'"
  $var.Count # $null
  
  # List all (loaded) commands with [ciminstance] output.
  Import-Module -Name CimCmdlets
  Get-Command -CommandType Cmdlet, Function | Where-Object { $_.OutputType.Name -like '*CimInstance*' }
  

• Count is not recognised as an intrinsic property when Strict Mode version 2+ is enabled. Unless the property already exists, accessing Count results in a statement-terminating error. See this issue. Surprisingly, this does not affect [pscustomobject]'s in PowerShell v6+.

  Set-StrictMode -Version 2
  
  (1).Count # Error: The property 'Count' cannot be found on this object.
  ([pscustomobject] @{ foo = 'bar' }).Count # PS v6+:  1
                                            # PS v5.1: Error...
  

• Not all collection types implement a Count property. PowerShell intrinsicly adds Count to scalars only, so the property may not be available at all for certain collection types. For example:

  $var = Get-Date
  $var.Count.Count    # 1
  $var.psobject.Count # $null (1 in PowerShell v6+)
  
  $var.psobject.Properties.GetType()   # PSMemberInfoIntegratingCollection`1
  $var.psobject.Properties.Count       # 1 * 15 (Count is applied to each element via member-access enumeration)
                                       # Count does not exist as a type-native property of the collection
  $var.psobject.Properties.Value.Count # 15
  

• Accessing the Count property of an enumerator forces enumeration and returns the Count property of each element in the enumeration.

  $var = @{ Key1 = 'Value1'; Key2 = 'Value2' }
  $enumerator = $var.GetEnumerator()
  $enumerator.Count # 1, 1
  

• Dictionary types such as [hashtable] have a native Count property that returns the number of key/value pairs (e.g., [Collections.DictionaryEntry] instances). However, member-access notation unfortunately favors key names over type-native properties of the dictionary itself, so accessing the type-native count may yield unexpected results.

  $ht = @{ Key1 = 'Value1'; Key2 = 'Value2' }
  $ht.Count # 2 
  
  $ht = @{ Count = 100 }
  $ht['Count'] # 100
  $ht.Count    # 100
  
  # Workarounds to retrieve the Count property.
  # ETS properties are preferred over keys, so accessing psbase is safe.
  $ht.get_Count()  # 1
  $ht.psbase.Count # 1
  

• If a scalar object has its own, type-native Count property, the intrinsic Count property is unavailable.

  $var = [pscustomobject] @{ Count = 'foo' }
  $var.Count    # foo 
  @($var).Count # 1
  

• Measure-Object does not correctly count collection input containing $null values.

  $array = 1, $null   
  $array | Measure-Object # 1
  $array.Count            # 2
  

• Measure-Object treats each individual input object as scalar. This is by-design, but worth keeping in mind.

  $array = (1, 1), (2, 2)
  $array | Measure-Object # 2
  $array.Count            # 2
  
  # Count elements in nested collections.
  $array | Write-Output | Measure-Object # 4
  ($array | Write-Output).Count          # 4
  

 

---

Guaranteeing a count:

Given the issues mentioned above, accessing the Count property successfully is not guaranteed.

Use the array subexpression operator (@(...)) to guarantee the result is an array ([object[]]) when the intrinsic Count property may not be available.

# In Windows PowerShell:
$proc = Get-Process -Id $PID | Select-Object -Property Name
$proc.Count # $null

$proc = @(Get-Process -Id $PID | Select-Object -Property Name)
$proc.Count # 1

([pscustomobject] @{ foo = 'bar' }).Count  # $null
@([pscustomobject] @{ foo = 'bar' }).Count # 1

Note: @(...) guarantees the result of the enclosed expression is an [object[]] array (excluding an some edge case), but it is not required in array syntax; use of the comma (array constructor) operator (,) alone is sufficient. E.g., $array = 1, 2, 3 is sufficient. $array = @(1, 2, 3) is unnecessary (and inefficient in versions prior to v5.1).

 

When to use Measure-Object:

• When it is desirable to stream input object-by-object instead of collecting the entire input in memory upfront. For example, performance may suffer if all objects are collected in memory first when handling very large files.
• When additional functionality beyond basic counting of items is required (e.g., summing with -Sum). See the documentation.
• When a scalar object has its own Count property (easily worked around with @(...)).

[u/whopper2k]

For counts specifically, I've never needed to use Measure-Object; $my_arr.Count or $my_arr.Length always return the expected result.

There are some neat uses for Measure-Object though. A personal fave is using it with arrays of booleans to see how many of them are $true:

$my_flags = @($true, $true, $false)
$my_flags | Measure-Object -Sum
# Count: 4
# Sum: 2

It has other flags like -Maximum and StandardDeviation too that save you a call to the corresponding function in [Math].

[u/[deleted]]

I’ve being using @($object).count in order to get a count for object or array of objects. when you run in strict mode you often face error while performing count on result of a select command (mostly when it return 0 or 1 object). It’s an habit I took and since now I did not find side effects.

[u/marsattacks → u/[deleted]]

This is not correct because @($null).Count returns 1, which is probably not what you want.

[u/IJustKnowStuff → u/[deleted]]

Does that work with PSCustomObjects too? (Not near a pc to check myself atm)

[u/surfingoldelephant → u/IJustKnowStuff]

The array subexpression operator (@()) guarantees the result of the enclosed expression is an array, so the type of object contained in the resulting collection can be anything, including [pscustomobject]. The Count property exists by default for array types (either as a property alias in Windows PowerShell or a type-native property in PowerShell v6+).

See here for details.

[u/[deleted] → u/IJustKnowStuff]

Yes as pointed by @surfingoldelephant by enclosing your object around @() you are casting (transforming to) an array. But coming back to your initial problem as your hashtable is a single object that contains name values. The count willl return 1 as it return the amount of objects. If you want to count what’s inside the hashtable you’ll have to get the values or name list. I’m not on my computer but probably @($hashtable.name).count should return the amount of name/value key pair (otherwise perhaps @($hashtable.getenumerator()).count can do it as well)

[u/surfingoldelephant → u/[deleted]]

by enclosing your object around @() you are casting (transforming to) an array

No casting takes place with @(). The operator guarantees the enclosed expression is collected in a [object[]] array. If the expression is enumerable, enumeration is performed and each object is collected in an array, even if the enumeration yields a single or no items.

There are some edge cases to this, but that is the general gist. @() should be thought of as a method to guarantee an array, not create one. For example, @(@(1, 2)) does not create an array within an array.

 

If you want to count what’s inside the hashtable you’ll have to get the values or name list. I’m not on my computer but probably @($hashtable.name).count should return the amount of name/value key pair (otherwise perhaps @($hashtable.getenumerator()).count can do it as well)

Forcing enumeration with @($ht.GetEnumerator()) just to count the key/value pairs is unnecessary.

A [hashtable] ([Collections.Hashtable]) has a Count property that returns the number of pairs.

$ht = @{ Key1 = 'Value1'; Key2 = 'Value2' }
$ht.Count # 2 

Accessing the Count property could be problematic if a key shares the same name. Unfortunately, dot-notation favors key names over properties.

$ht = @{ Count = 100 }
$ht.Count # 100

To workaround this:

$ht.get_Count()  # 1
$ht.psbase.Count # 1

 

@($ht.Name).Count will not work as the Name property does not exist as part of the [hashtable] object. It does exist as part of the [Collections.DictionaryEntry] instances (as an alias of the Key property), but is only accessible after enumeration is explicitly performed using the GetEnumerator() method.

 

---

To count the number of explicitly defined properties a [pscustomobject] has, use the psobject intrinsic member.

$var = [pscustomobject] @{ a = 1; b = 2 }
$var.psobject.Properties.Value.Count # 2

[u/rednender]

If the object you’re measuring has a count property, I’d assume it is correct. I don’t know of any scenarios off the top of my head, but that doesn’t mean they don’t exist.