Is there anything more that can be done to reduce the overhead of calling functions? #15729
Replies: 6 comments 15 replies
-
|
You are more likely to encounter worse performance on PS7. No improvements have been made in parameter bindings. |
Beta Was this translation helpful? Give feedback.
-
|
The fastest advisable way will probably be That said, something with using namespace System.Management.Automation
$script:value = 0L
$script:pipe = {
& {
[CmdletBinding()]
param(
[Parameter(ValueFromPipeline)]
[int64] $i
)
process {
$script:value += $i
}
}
}.GetSteppablePipeline([CommandOrigin]::Internal)
$script:pipe.Begin(<# expectingInput: #> $true)
for ($i = 0L; $i -lt 1000L; $i++) {
$script:pipe.Process($i)
}Also FWIW there's a huge amount of pit falls when benchmarking (especially very small benchmarks like these) in PowerShell. Dot sourcing, the scope you pull access variables from, and a whole lot of other factors can make something look like worse performance than it actually is in a real world script. |
Beta Was this translation helpful? Give feedback.
-
Appreciated, but the effect was happening in my much larger scripted process (looping through a lot of DB rows, performing much more slowly after the initial loop innards were split into readable functions), and I wanted to post a minimal example to recreate.
I initially discounted
I'd not heard of this (and the docs leave something to be desired). I see similar (albeit slightly higher) timings to Additional tests (based on @SeeminglyScience's comments): Current results (I added the Result column as a checksum, but it is outside of the timing):
|
Beta Was this translation helpful? Give feedback.
-
|
Has there been any suggestion and/or advancement in a MSIL JIT/compile routine for Powershell code? I saw PS2EXE, but that looks like it bundles a host and feeds your script to it, rather than compiling, per se... |
Beta Was this translation helpful? Give feedback.
-
|
@SeeminglyScience - the pure PS function is compiled after ~30 invocations? Does that improve the parameter binder time calling the function (e.g. inside a tight loop) or "just" the time taken once inside the function? If I had a short-circuiting conditional return at the top of my function, could I spin it ~30 times at the start to trigger the compile, then enjoy a high-speed invocation later, or would it only compile the short-circuited path previously seen? @iSazonov - I'll be honest, I know nothing about PowerShell classes, but I bet, as soon as I start trying to use them, I'll end up on on a server running a PS that can't understand them... |
Beta Was this translation helpful? Give feedback.
-
|
If you use Windows PowerShell the latest supported version is 5.1 and if you create a PS class it will work on every system where PS 5.1 is installed. |
Beta Was this translation helpful? Give feedback.
-
|
@iSazonov - the latest supported version might be 5.1, but the latest deployed version is seldom thus. I've seen entirely "up to date" Windows systems, in the wild, with 2.0, 3.0, etc. And, with the fragmentation of .NET, I don't see that changing, any time soon. ...but that's a separate discussion :-) I will look into classes in 5.1, and see if I they improve anything with regards to function call overhead. |
Beta Was this translation helpful? Give feedback.
-
Any scriptblock, yeah.
The latter.
Technically yeah, but if 30 invocations is a meaningful portion of total run time then you are not likely at a scale where interpreted vs compiled makes any noticeable difference. |
Beta Was this translation helpful? Give feedback.
-
Agreed, and---since my pain is in the function call, not the implementation (although I'm sure the implementation leaves much to be desired)---not going to improve my runtime. Was just trying to get a feel for whether it was sensitive to branching. |
Beta Was this translation helpful? Give feedback.
-
|
So, it seems the route that I've gone ( Happy to open this up to ways in which further development of PowerShell could improve on the situation, especially in script/module code... |
Beta Was this translation helpful? Give feedback.
-
|
I think PowerShell can already deliver the performance you are looking for, see below. (And the overhead for parameter binding is not significant, I don't think) |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I take that back, the overhead for parameter binding can indeed be significant. |
Beta Was this translation helpful? Give feedback.
-
|
Try using the pipeline, and omit an explicit parameter block: [CmdletBinding()]
Param(
[Int64[]] $Iterations = (1000,10000,100000,1000000) #,10000000)
)
$value = 999
function func0 {
# this is the way
process {
$value += $_
}
}
function func0B {
param(
[parameter( mandatory=$true,ValueFromPipeline=$true)]
$x
)
process {
$value += $x
}
}
function script:func1 { # a standard function
Param([Int64]$n)
$script:value += $n
}
$script:func2 = { # a script block, which I can .Invoke() or .InvokeReturnAsIs()
Param([Int64]$n)
$script:value += $n
}
$script:func3 = [Action[Int64]] { # a script block coerced to an Action<>
Param([Int64]$n)
$script:value += $n
}
$cs = (Add-Type -Language CSharp -PassThru -TypeDefinition @"
public static class Lib_$([Guid]::NewGuid().ToString("N"))
{ // a c# function, which I can passthru and call directly
public static void DoIt(ref long orig, long n)
{
orig += n;
}
}
"@)[0]
$sbCsFuncPipe = `
{
process {
$cs::DoIt([ref]$script:value, $_ )
}
}
foreach ($script:iter in $Iterations) {
Write-Output (New-Object PSObject -Property @{
'Method' = 'Unrolled - make this wide ...'
'Iterations' = $script:iter
'Timing' = (Measure-Command {
[Int64] $script:value = 0L
foreach ($i in (1..$script:iter)) {
$script:value += $i # just don't call a function
}
})
})
Write-Output "value: $($script:value)"
Write-Output (New-Object PSObject -Property @{
'Method' = 'func zero'
'Iterations' = $script:iter
'Timing' = (Measure-Command {
[Int64] $script:value = 0L
$func = $function:func0
$thisMany = 1 .. $script:iter
# use the pipeline
$thisMany | . $func
# 1 .. $script.iter | . $func
})
})
Write-Output "value: $($script:value)"
Write-Output (New-Object PSObject -Property @{
'Method' = 'func zero B'
'Iterations' = $script:iter
'Timing' = (Measure-Command {
[Int64] $script:value = 0L
$func = $function:func0B
# use the pipeline, with function that has a named parameter
$thisMany = 1 .. $script:iter
$thisMany | . $func
# ( 1 .. $script.iter ) | . $func
})
})
Write-Output "value: $($script:value)"
Write-Output (New-Object PSObject -Property @{
'Method' = 'func zero B via x'
'Iterations' = $script:iter
'Timing' = (Measure-Command {
[Int64] $script:value = 0L
$func = $function:func0B
# use the pipeline, with function that has a named parameter,
# but via `ForEach-Object`, as if you didn't know that the
# function accepted pipeline input
$thisMany = 1 .. $script:iter
$thisMany | Foreach-Object { . $func -x $_ }
# ( 1 .. $script.iter ) | Foreach-Object { . $func -x $_ }
})
})
Write-Output "value: $($script:value)"
Write-Output (New-Object PSObject -Property @{
'Method' = 'csfunc'
'Iterations' = $script:iter
'Timing' = (Measure-Command {
[Int64] $script:value = 0L
foreach ($i in (1..$script:iter)) {
$cs::DoIt([ref]$script:value, $i)
}
})
})
Write-Output "value: $($script:value)"
Write-Output (New-Object PSObject -Property @{
'Method' = 'csfunc via pipeline'
'Iterations' = $script:iter
'Timing' = (Measure-Command {
[Int64] $script:value = 0L
# use the csharp function indirectly, via a powershell function
# that accepts pipeline input
$thisMany = 1 .. $script:iter
$thisMany | & $sbCsFuncPipe
})
})
Write-Output "value: $($script:value)"
Write-Output "-----------`n"
# Don't even bother with these:
# Write-Output (New-Object PSObject -Property @{
# 'Method' = 'func zero B via foreach'
# 'Iterations' = $script:iter
# 'Timing' = (Measure-Command {
# [Int64] $script:value = 0L
# $func = $function:func0B
# foreach ($i in (1..$script:iter)) {
# & $func $i
# }
# })
# })
# Write-Output (New-Object PSObject -Property @{
# 'Method' = 'func1C'
# 'Iterations' = $script:iter
# 'Timing' = (Measure-Command {
# [Int64] $script:value = 0L
# $func = $function:func1
# foreach ($i in (1..$script:iter)) {
# & $func $i
# }
# })
# })
# Write-Output (New-Object PSObject -Property @{
# 'Method' = 'func1'
# 'Iterations' = $script:iter
# 'Timing' = (Measure-Command {
# [Int64] $script:value = 0L
# foreach ($i in (1..$script:iter)) {
# script:func1($i)
# }
# })
# })
# Write-Output (New-Object PSObject -Property @{
# 'Method' = 'func1B'
# 'Iterations' = $script:iter
# 'Timing' = (Measure-Command {
# [Int64] $script:value = 0L
# foreach ($i in (1..$script:iter)) {
# script:func1 $i
# }
# })
# })
# Write-Output (New-Object PSObject -Property @{
# 'Method' = 'func2'
# 'Iterations' = $script:iter
# 'Timing' = (Measure-Command {
# [Int64] $script:value = 0L
# foreach ($i in (1..$script:iter)) {
# $script:func2.Invoke($i)
# }
# })
# })
# Write-Output (New-Object PSObject -Property @{
# 'Method' = 'func2-asis'
# 'Iterations' = $script:iter
# 'Timing' = (Measure-Command {
# [Int64] $script:value = 0L
# foreach ($i in (1..$script:iter)) {
# $script:func2.InvokeReturnAsIs($i)
# }
# })
# })
# Write-Output (New-Object PSObject -Property @{
# 'Method' = 'func3'
# 'Iterations' = $script:iter
# 'Timing' = (Measure-Command {
# [Int64] $script:value = 0L
# foreach ($i in (1..$script:iter)) {
# $script:func3.Invoke($i)
# }
# })
# })
} |
Beta Was this translation helpful? Give feedback.
-
Method Timing Iterations
------ ------ ----------
Unrolled - make this wide ... 00:00:00.0146774 1000
value: 500500
func zero 00:00:00.0348789 1000
value: 500500
func zero B 00:00:00.0381645 1000
value: 500500
func zero B via x 00:00:00.1808342 1000
value: 500500
csfunc 00:00:00.0214909 1000
value: 500500
csfunc via pipeline 00:00:00.0387765 1000
value: 500500
-----------
Unrolled - make this wide ... 00:00:00.0404534 10000
value: 50005000
func zero 00:00:00.0458774 10000
value: 50005000
func zero B 00:00:00.2083047 10000
value: 50005000
func zero B via x 00:00:01.9403793 10000
value: 50005000
csfunc 00:00:00.0772508 10000
value: 50005000
csfunc via pipeline 00:00:00.0888102 10000
value: 50005000
-----------
Unrolled - make this wide ... 00:00:00.3898073 100000
value: 5000050000
func zero 00:00:00.4523467 100000
value: 5000050000
func zero B 00:00:02.0723845 100000
value: 5000050000
func zero B via x 00:00:17.0378065 100000
value: 5000050000
csfunc 00:00:00.7726129 100000
value: 5000050000
csfunc via pipeline 00:00:00.8940438 100000
value: 5000050000
-----------
Unrolled - make this wide ... 00:00:03.8376150 1000000
value: 500000500000
func zero 00:00:04.4173799 1000000
value: 500000500000
func zero B 00:00:20.3821910 1000000
value: 500000500000
func zero B via x 00:03:01.2116492 1000000
value: 500000500000
csfunc 00:00:08.7834210 1000000
value: 500000500000
csfunc via pipeline 00:00:09.8206504 1000000
value: 500000500000
----------- |
Beta Was this translation helpful? Give feedback.
-
|
It appears that in this example, there mere presence of a parameter block increases the execution time by a scalar multiple - provided that this parameter accepts pipeline input, and that the function is invoked in the context of a pipeline. However, if the direct invocation of the function is not done in the immediate context of a pipeline, it starts to balloon in what appears to be an order of magnitude. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting findings regarding the non-parametised pipeline, but pipelining doesn't always lend itself to a multi-step loop body, which is where I found myself after I'd refactored my original script into functions (e.g. for readability): Also, as an aside, does |
Beta Was this translation helpful? Give feedback.
-
|
I haven't checked directly by reading the source, but I believe the So, in our contrived example, we are evaluating the expression foreach ($script:iter in $Iterations) {
# let's just do this once at the top, or each iteration
$thisMany = 1 .. $script:iter
Write-Output (New-Object PSObject -Property @{
# blah blah, code continues... etc. and so forth... But this doesn't answer your question about the "generated on the fly" aspect. For this you need some sort of iterable gizmo, likely in .NET you'll want something that implements I apologize; I'm a bit fuzzy on the details at the moment. Surely something in the above text is half wrong or misleading, but I hope the the gist of it is clear. Javascript generators do much the same thing, and it would appear that there has been quite a bit of cross-pollination between the .NET and ECMAScript thinking. As a consequence I get things mixed up sometimes. Anyway, to return from my tangent, I'll just end with stating that I have indeed written some code which deals with enormous amounts of data, where "enormous" means "cannot possibly fit in memory", and which uses the Enumerable/Generator like patterns I describe above, to ingest the data chunk by chunk, and passing each chuck down a pipeline. In this case the pipeline I created is simply used to create a facility which is basically just a composition of number of smaller functions, each being invoked in order, based on the results of the previous function in the sequence. This code was written entirely in PowerShell, without resorting to C# at any point. In fact, that's all a pipeline really is: a really elegant (if you squint in just the right way) and innovative (no arguing this point) way to offer "function composition". From a conceptual point of view, a pipeline you write in PowerShell can be thought of simply as a larger function (in the computer science sense of the word) which is comprised of a sequence of smaller functions. (Modulo the fact that PowerShell is all "YOLO, dude!" about things like referential transparency, and [... insert long list of concepts from functional programming...]) So, if your use case involves something like processing data retrieved from an RDBMS, and:
then the Enumerator/Generator pattern would be just what you described as needing. You obviously already have the code which connects to the database and retrieves the data, what you need now is something that contains that logic, but exposes access to the data by way of an Enumerator. You can write it in such a way that you grab data in chunks of 1,000 rows, but the enumerator only parcels out one row at a time. When the rows are gone, it just goes and grabs the next 1,000 rows. Last thought. When you write: (1..100) | %{
# something familiar about this pattern...
Do-Thing1 -something -funky $_ # this function is composed of a sequence of operations...
Do-Thing2 -something -else # hmm, "sequence of operations"... sounds suspiciously
Do-Etc # like something I've run across before...
# oh, right! That's what a pipeline is !
}I see this instead: function Operation1 { process { $fromSource = $_; <# yadda #>; $result } }
function Operation2 { process { $fromOp1 = $_; <# yadda #>; $result } }
function Operation3 { process { $fromOp2 = $_; <# yadda #>; $result } }
$manyThings = [SourceOfTruth]::GetAllThings();
$manyThings `
| `
& Operation1 `
| `
& Operation2 `
| `
& Operation3 `
| `
Out-ToWhateverStorage `
;Making this observation is a far cry from actually recommending that you switch your implementation to one that uses pipelining. While the concepts are really simple, once one wraps one's head around them, in actual practice there are many pitfalls and unexpected weird corners to PowerShell. Such skill and knowledge as I possess, the level of which I leave to the observer to determine, (especially since from my subjective view it seems to swell and contract on a weekly basis), was arrived at only after years of significant pain and frustration. So, I'm just telling you two things:
Whether or not you choose to embark on this adventure is not something I should offer any input on. Just consider how much faster the |
Beta Was this translation helpful? Give feedback.
-
|
P.S. When I use the word "function", I usually almost always mean "scriptblock". This is because the "scriptblock" is PowerShell's idea of the "anonymous function". The anonymous function is a concept central to many languages. So much so that in my head when I hear "function", I think "anonymous function", which maps directly to "scriptblock" in the context of PowerShell. Also, calls to So any code that I write that isn't "client facing" is usually written exclusively in terms of scriptblocks. |
Beta Was this translation helpful? Give feedback.
-
|
Parameter binding area is very complex and sensitive. That's the price of versatility. The current implementation of parameter bindings is well optimized. It is unlikely that we can do anything better there directly.
Unfortunately, we do not have community experts who would implement improvements in this area. |
Beta Was this translation helpful? Give feedback.
-
Considering the basest of contrived examples, below:
...the results of this may be surprising:
My guess is that the woeful performance of
func1is probably due to parameter binding but---at least to me---the overhead of calling a "normal" function is disappointing, especially after seeing a concerted effort to make a larger script more readable plummett performance by as much as 20x -- significantly more if there were multiple function calls per iteration.Appreciating that rewriting the entire script in C# is...less than ideal...are there any (preferably backward-compatible) approaches, in general, that I have missed which might improve upon the
func2/func3best-case pure-Powershell approaches?I'm personally stuck with running in Win PS -- readings were taken from Win10/PS5.1 -- I can't shift my current stack away from WinPS at the moment but, for knowledge's sake, is there anything in PS6/7+ that significantly improves on this?
Or is splitting work into readable functions just a write-off?
Beta Was this translation helpful? Give feedback.
All reactions