.NET or not .NET - Where

Dotnet or not Dotnet this is the question we will ask in this post

Lets find out if the .NET .Where() method is significantly faster than their equivalent in native PowerShell

In this post, we'll compare the performance of native PowerShell methods with their .NET counterparts, specifically focusing on the .Where() method. We'll also use the [Linq.Enumerable] class to analyze a different dataset – passenger data from the Titanic – instead of the usual Active Directory user data.

Before we dive in, I want to give a shoutout to the Hamburg PowerShell User Group, where I participated in my first PowerShell Hackathon in 2022 for bringing up the idea. We analyzed public transportation data from Hamburg, which was a fun challenge. If you're interested in using the Titanic data for your own analysis, check out awesomdata Github

The Code

We'll be using three different methods to compare performance:

#linq method
$StopWatch = New-Object System.Diagnostics.Stopwatch
$StopWatch.Start()
$delegate = [Func[object,bool]] { $args[0].Sex -eq "male" }
$Result = [Linq.Enumerable]::Where($Import, $delegate)
$Result = [Linq.Enumerable]::ToList($Result)
$StopWatch.Stop()
$TestList.add([PSCustomObject]@{
    Method = "Linq Where-Method"
    ResultCounter = $Result.Count
    TimeElapsed = $StopWatch.Elapsed
    TimeElapsedMS = $StopWatch.ElapsedMilliseconds
})

#Piped Where Method
$StopWatch = New-Object System.Diagnostics.Stopwatch
$StopWatch.Start()
$Result = $Import | Where-Object{$_.Sex -eq "male"}
$StopWatch.Stop()
$TestList.add([PSCustomObject]@{
    Method = "Piped Where-Method"
    ResultCounter = $Result.Count
    TimeElapsed = $StopWatch.Elapsed
    TimeElapsedMS = $StopWatch.ElapsedMilliseconds
})

#.Where() Method
$StopWatch = New-Object System.Diagnostics.Stopwatch
$StopWatch.Start()
$Result = $Import.Where({$_.Sex -eq "male"})
$StopWatch.Stop()
$TestList.add([PSCustomObject]@{
    Method = ".where()-Method"
    ResultCounter = $Result.Count
    TimeElapsed = $StopWatch.Elapsed
    TimeElapsedMS = $StopWatch.ElapsedMilliseconds
})

A Scary Realization: Inconsistent Execution Times

As I was checking the results and testing the reliability of my code, I executed my code segments multiple times. I noticed that there were times when there was another winner when it comes to execution time, and the results were somewhat different each time I ran the code. I was wondering how this could happen, so I decided to switch from PowerShell Version 7.x to 5.1, but the results were nearly the same.

To investigate this further, I performed the same action 101 times for each version of PowerShell on my machine and took the average of each 101 runs, and put them into a table.

The Results: Comparing PowerShell Versions 7.X and 5.1

Here are the results of my tests:

|AverageOf101ms|Method|PSVersion| |:--|:--|:--| |3,0495049504950495|Linq Where-Method|7| |5,851485148514851|Piped Where-Method|7| |1,3465346534653466|.where()-Method|7|

PowerShell Version 5.1

|AverageOf101ms|Method|PSVersion| |:--|:--|:--| |6,88118811881188|Linq Where-Method|5| |11,2871287128713|Piped Where-Method|5| |3,88118811881188|.where()-Method|5|

The Conclusion: Optimal Methods and Versions

Based on my tests, all methods are optimized for PowerShell version 7.X, but in the test cases, the .where() method was the winner. This was also predicted by @guyrleech on Twitter, which confirms the reliability of the test results. It is also noteworthy that the piped method was slower than the rest, especially in PowerShell 5.1. In terms of write- and readability, the Linq way is somewhat challenging.

Our Amazing Sponsors