.NET or not .NET - Where

.NET or not .NET - Where

Written by Christian Ritter on Mar 23rd, 2023 Views Report Post

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.

If you have any thoughts or feedback on this topic, feel free to share them with me on Twitter at Christian Ritter.

Best regards,

Christian.

Comments (0)