powershell-performance optimization, multi-threading, speed-up

• PowerShell Optimization and performance testing

Overview

PowerShell has been around for a long time, and many of the basic problems have been well addressed. For scripting people, the GET-HELP help documentation for PowerShell, the Internet, and community resources, what the vast majority of common tasks should be, and how they should be done, should be able to find answers quickly. Once the script is written, there is no bug, ready to put into production environment, maybe some other problems will surface, just as we usually discuss less. How to write better scripts as much as possible? More efficient, enhanced tools to improve the scripts that are already in use. And these just need a few different questions and ideas to deal with. This will start to liberate the scripting people from the end user and the administrator's world and into the developer domain. Although some people are reluctant to pick up another hat and mix it with the development circle. But there really is no better tool for you to open another door in the parallel universe than PowerShell. So let's take a look at some of the basic concepts of maximizing scripting performance, and then go to some deep questions to see how far we are from the challenge limit.

There are two key areas of PowerShell that don't give them the attention they deserve, which is optimization and performance testing. Optimization means that scripts are designed and modified to minimize time and resource usage during the run. In short, it's about transforming the code so that it runs quickly and efficiently. Performance testing always goes hand-in-hand with optimization and results from script execution to determine whether optimization is effective. This way really can make clear the so-called "transformation", is not really changed. There is also an optimization without performance testing to avoid many problems. Here's a quote, I've seen many times about the no-Test optimization sentence:

Excellent engineering comes from predictable costs and creates predictable results. What I want to say is that there is no project without measurement.

Referenced from: "Web Application Performance Test Guide".

"No engineering without measurements" Indeed, this is an old article, but its point of view is still as meaningful as it was when it was first published. The only way is to honestly verify that all your rework will benefit from the real world results. And, performance testing is the key way to complete it.

Default order for best execution

On the basis of the terms just drafted, let us discuss some of the basic points of PowerShell that should be known in advance. A better understanding of PowerShell is a prerequisite. If even basic knowledge is not understood, the concept of high-level discussion is not worth much. For example, Bruce Payette lists an outline of the best execution sequence, based on the type of command you are running. In 2.1.2 chapters (in the command category), from 30 pages to 34 pages, he said that according to the speed of execution, the order of the command type is as follows:

1. Cmdlets: Compiled binaries

2. Functions: script code that resides in memory

3. Script (script command): A function or command saved in a PS1 file

4. Native Win32 executable: traditional executable file

So, if you have a Win32 executable file, you might be porting it into a script, a function, or even a cmdlet that might bring a speed boost. This may not always be possible, but there are many scenarios where porting your functionality upstream can improve the efficiency of your PowerShell code execution. The key point here is that understanding how to use different kinds of commands may affect the extent to which your scripts are ultimately optimized.

Optimization considerations

By performing the basic order of optimization, we can begin to refine your script by presenting some questions and then following these questions.

When performing optimizations, the following questions are frequently asked:

• Do I use the correct constructor in this case?

• Do I do a lot of things I don't need?

• Do I use too many objects?

• Do I use a lot of shared resources?

• Do I use the appropriate collection? Another question: Do I use the right or the best set to accomplish this task? is the

• Pipeline the best way? Does

• Have additional command models that might be better?

• Is my thinking about objects appropriate?

• Have I used-filter (if any)?

• My pre-defined variable is not used?

• Is it useful to use job and runspaces for some tasks?

• Is my loop designed to be efficient?

• Foreach-object I use, would it be better to use for?

• When you have  foreach-object in your script, do you use the begin-process-end structure?

• Do you use advanced functions?

• Did you do a parameter check?

• Have you used strict mode (Strict-mode)?

• When I connect remotely, such as Active Directory, I don't limit the number of returned objects?

• When I get data from the network, I don't use filter,where and other parameters to specify the return value to limit the number of results returned?

• Did I get the data for the first time, save it in a variable so that I can use it next time?

• Is there a low-level scenario that is more efficient? Like. NET? P/invoke?

• Do you use pipelines to pass collections instead of using a large collection store?

• Did you test for an unnecessary conditional judgment?

Here's a demonstration of why the above questions can cause problems:

Do I use-filter (if any)?

The following script fragment demonstrates how to use the appropriate command's-filter parameter to improve efficiency. For example I use Get-childitem-filter and Get-childitem | Where {$_. Name-eq ' 100Mb.txt ' search for a file "C:\test\100Mb.txt".

123456789101112131415

Clear-Host1..10 | ForEach-Object {"Command: output $_""-" * 25$test1 = { Get-ChildItem -Path C:\test -Filter 100mb.txt | Out-Null }$test2 = { Get-ChildItem -Path C:\test | Where {$_.Name -eq ‘100Mb.txt‘} | Out-Null }$results1 = (Measure-Command -Expression $test1).Ticks$results2 =(Measure-Command -Expression $test2).Ticks"{0}`t`t{1}" -f ‘-filter‘,$results1"{0}`t`t`t{1}" -f ‘Where‘,$results2"""{0}`t`t{1:N}" -f ‘Difference‘,($results1/$results2)""}

Tests have shown that in this very small case, using the where in the-filter parameter than the popular foreach-object, the speed can be increased by 4-8 times. We typically prefer to use foreach, but simple filter filtering can make a very meaningful increase in script speed.

I use the foreach-object, if use for will not be better?

The following script fragment we use Foreach-object to replace the For loop for testing:

123456789101112131415161718192021

"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: evaluate 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)

After this code is executed on my machine, the result is as follows:

Command:output 1-------------------------foreach 903091for 18212Difference 49.59command:evaluate 1-eq 1------------- ------------foreach 907313for 22254Difference 40.77

The test shows that Foreach-object is 40-50 times slower on my machine than using the for loop directly. Because foreach iterates over the collection and controls it, it takes time. So it's also a point to consider when optimizing scripts comprehensively.

Did I test an unnecessary condition to judge?

Most of the time, we used to judge whether the condition was true or false, and there were some simpler ways of actually not having to evaluate it. For example, judging a variable like this is true?

1234	if(1 -eq$true){Do-Something}

You can simply hand over the judgment directly to if it is enough.

1234	if(1){Do-Something}

To test the difference, I simply wrote a script and found that skipping the if judgment would return about 5% of the performance.

1234567

$test_001 = { if(1 -eq $true) {1} else {0}}$test_002 = { if(1) {1} else {0}}Get-ChildItem variable:\test_* |ForEach-Object {Measure-Command -Expression {1..100000 | % { $_ }} |select TotalSeconds}

Results after the run:

TotalSeconds------------12.122056211.732413

The example is small, but it can be explained that if a Boolean type of judgment in the IF statement, can directly omit the judgment, but can improve performance.

Performance Test Considerations

There are a lot of things to be aware of in performance testing, and here are some key points to review your commands and scripts.

• Have you tested enough iterations and changes to take the average result?

• Will your tests fluctuate with the data and structure system?

• Can the results of the test be reproduced?

• Can you explain why your tests can verify your changes and optimizations?

• If the first iteration is faster than the subsequent iteration, it is possible that the result is cached. If so, you can insert a pause between iterations, flush the cache, and get consistent results.

• Speed up your PowerShell for loop by up to four times times

• Optimize the performance and memory consumption of PowerShell

• PowerShell Speed and multithreading

• Several tips for optimizing PowerShell scripts

• Lightweight PowerShell Performance test

Reference:

Http://www.pstips.net/optimization-and-performance-testing.html

This article comes from the "Ricky's blog" blog, please be sure to keep this source http://57388.blog.51cto.com/47388/1649667

powershell-performance optimization, multi-threading, speed-up