从答案中提到的任何性能测量命令中得出(不正确的)结论。除了查看(自定义)函数或命令的裸调用时间之外,还应考虑许多缺陷。
Sjoemel 软件
'Sjoemelsoftware' voted Dutch word of the year 2015
Sjoemelen是作弊的意思,sjoemelsoftware这个词因大众汽车排放丑闻而应运而生.官方定义是“用于影响测试结果的软件”。
我个人认为“Sjoemelsoftware”并非总是故意创建以欺骗测试结果,而是可能源于适应类似于如下所示测试用例的实际情况。
例如,使用列出的性能测量命令Language Integrated Query (LINQ)(1) 通常被认为是完成某事的禁食方法,而且通常是,但肯定不总是!任何人如果测量与原生 PowerShell 命令相比 40 倍或更多的速度增加,则可能是在测量错误或得出错误的结论。
重点是某些 .Net 类(如 LINQ)使用lazy evaluation(也称为延迟执行(2))。这意味着当将表达式分配给变量时,它几乎立即完成,但实际上它还没有处理任何事情!
假设您 dot-source 您的 . .\Dosomething.ps1 命令具有 PowerShell 或更复杂的 Linq 表达式(为了便于解释,我已将表达式直接嵌入到 Measure-Command 中):
$Data = @(1..100000).ForEach{[PSCustomObject]@{Index=$_;Property=(Get-Random)}}
(Measure-Command {
$PowerShell = $Data.Where{$_.Index -eq 12345}
}).totalmilliseconds
864.5237
(Measure-Command {
$Linq = [Linq.Enumerable]::Where($Data, [Func[object,bool]] { param($Item); Return $Item.Index -eq 12345})
}).totalmilliseconds
24.5949
结果很明显,后面的 Linq 命令比第一个 PowerShell 命令快了大约 40 倍。不幸的是,没有那么简单......
让我们显示结果:
PS C:\> $PowerShell
Index Property
----- --------
12345 104123841
PS C:\> $Linq
Index Property
----- --------
12345 104123841
正如预期的那样,结果是相同的,但如果您仔细观察,您会注意到显示$Linq 结果比显示$PowerShell 结果花费的时间要长得多。
让我们通过检索结果对象的属性来专门衡量 :
PS C:\> (Measure-Command {$PowerShell.Property}).totalmilliseconds
14.8798
PS C:\> (Measure-Command {$Linq.Property}).totalmilliseconds
1360.9435
检索$Linq 对象的属性比检索$PowerShell 对象的属性要长大约90 倍,而这只是一个对象!
还要注意另一个陷阱,如果你再做一次,某些步骤可能会比以前快很多,这是因为某些表达式已被缓存。
归根结底,如果您想比较两个函数之间的性能,您将需要在您的用例中实现它们,从一个新的 PowerShell 会话开始,并将您的结论基于完整解决方案的实际性能。
(1) 有关 PowerShell 和 LINQ 的更多背景和示例,我推荐 tihis 站点:High Performance PowerShell with LINQ
(2) 我认为两者之间存在细微差别与 惰性评估 的概念类似,结果是在 当需要时 计算出来的,与 延迟执行 是在系统 空闲时计算结果