Revision #4

Overview

PowerShell has been around long enough now that many of the basic questions are well-addressed. Between Get-Help, the internet and all the community resources available to scripters most of the what and how required to accomplish ordinary tasks can be answered quickly. Once you get your script working, bug-free, and, ready for roll out to production another set of questions may arise for which there is not as much discussion yet: how do I write the best possible script? Transforming a working script into a highly efficient, robust tool, however, requires a different set of questions and thought processes. This begins to bring the scripter out of the world of end use and administration into the arena of the developer. While some are reluctant to pick up another hat and put it in the development ring there is really no better tool than PowerShell to open the door into this parallel universe. So, let's take a glance at some basic concepts for maximizing a script's capabilities and then move onto some more in depth questions to see just how far we can push the envelope.

Two key areas of PowerShell scripting that do not get as much attention as they deserve are optimization and performance testing. Optimization means script modification designed or intended to reduce the time and resources required to run a script. In short, reworking code to run faster and more efficiently. Performance testing goes hand in hand with optimization and indicates the analysis of script results and execution to determine if optimization is effective. This is the way to really figure out if all those 'changes for the better' are really better. While optimization can be done without performance testing it begs plenty of questions. One quote I've seen a few different times comes to mind with regards to optimization without testing,

Great engineering comes from creating predictable results at predictable costs. In fact, I like to say that if you’re not measuring you’re not engineering. Performance Testing Guidance for Web Applications

"If you're not measuring you're not engineering." Granted, this is an old post, but, the point is as relevent today as it was when it was made. The only way to truly validate whether all the work you put into reworking something paid off or not it to give tangible, real world results. And, perforance testing is a key way to do just that.

Default Order of Optimal Execution

With terms now laid out let's talk about some basic PowerShell points of knowledge that should be covered before you start. Knowing PowerShell well is a given. If you do not know the basics, exploring advanced concepts will be of little value. For example, Bruce Payette outlined the order of optimal execution in PowerShell in Action based on which type of command you are running. In section 2.1.2 (Command Categories) from pages 30-34, he says the fastest operations will occur in this order:

1. cmdlets: compiled binaries
2. functions: memory resident script code
3. scripts (script command): functions/commands saved in .ps1 files 
4. native Win32 executables: traditional executables

So, if you have a Win32 executable, it is possible porting it to a script, a function or even a cmdlet may speed things up. This may not always be feasible, but, there are plenty of situations where porting your functionality upstream can produce improvements in your script's functionality. The key here is to understand how using different categories of commands may affect the final degree to which your script may be optimized.

Optimization Considerations

With the basic order of optimal exection covered we can look at some questions you can ask to begin the process of refining your scripts:

Questions to ask when optimizing

• Am I using the right construct for this situation?
• Am I doing too many or unnecessary operations?
• Am I working with too many objects?
• Am I using too many shared resources?
• Am I using collections correctly? Put another way: am I using the object for this collection?
• Is the pipeline the best approach?
• Is there another command model that may work better?
• Am I thinking about objects properly?
• Am I reinitializing variables unnecessarily?
• Is the task something for which jobs or runspaces could help?
• Are my loops designed efficiently?
• Am I using Foreach-Object when for will work just as well?
• Are you using begin/process/end with ForEach-Object and in your scripts?
• Are you using advanced functions?
• Are you doing parameter checking?
• Are you using Strict-Mode?
• Do I limit the number of objects I connect to remotely, such as in Active Directory?
• Do I limit the size of resultsets retrieved over the network, using filters, Where clauses, and parameters that specify values returned?
• Do I retrieve values once, and save in a variable if needed again later?

 Below are demonstrations of why the questions above can pose issues:

Am I using Foreach-Object when for will work just as well? 

In the snippet below the latency introduced by using Foreach-Object instead of for to loop through collections gets examined.

"Command: output 1"
"-" * 25
$test1 = { 1..1000 | % { 1 } }
$test2 = { for($i = 1; $i -le 1000; $i++) { 1 }}
$results1 = (Measure-Command -Expression $test1).Ticks
$results2 =(Measure-Command -Expression $test2).Ticks
"{0}`t`t{1}" -f 'foreach',$results1
"{0}`t`t`t{1}" -f 'for',$results2
""
"{0}`t`t{1:N}" -f 'Difference',($results1/$results2)
""
"Command: evaulate 1 -eq 1"
"-" * 25
$test3 = { 1..1000 | % { 1 -eq 1 } }
$test4 = { for($i = 1; $i -le 1000; $i++) { 1 -eq 1 }}
$results3 = (Measure-Command -Expression $test3).Ticks
$results4 =(Measure-Command -Expression $test4).Ticks
"{0}`t`t{1}" -f 'foreach',$results3
"{0}`t`t`t{1}" -f 'for',$results4
""
"{0}`t`t{1:N}" -f 'Difference',($results3/$results4)

When this command is run on my machine I get the following output:

Command: output 1
-------------------------
foreach 903091
for 18212

Difference 49.59


Command: evaulate 1 -eq 1
-------------------------
foreach 907313
for 22254

Difference 40.77


This code demonstrates that using ForEach-Object, on my machine, when I tested, was anywhere from 40-50 times slower than using a straight for loop. Now, there are times when ForEach-Object simplifies iteration and control, so, it has it's place, but, to fully optimize scripts this is a major point of consideration.