Fix debugger disable performance regression

[PaulHigin]

PR Summary

This is a fix for the performance regression found in issue #9884

PR Context

Even though the issue title indicate .net classes are slow to load, the repro steps make it clear that a general slow down can occur when a debug break point is set.

Repro:

$measure1 = measure-command{
  foreach($i in 1..10000){
    [System.Environment]
  }
} |select -ExpandProperty TotalSeconds

Set-PSBreakpoint -Variable "test" -Action {$null}

$measure2 = measure-command{
  foreach($i in 1..10000){
    [System.Environment]
  }
} |select -ExpandProperty TotalSeconds

Write-Host "First measurement took $measure1 seconds, Second measurement took $measure2"

>>First measurement took 0.0482474 seconds, Second measurement took 0.8722697

It turns out that this problem (based on the above repro) is due to a recent change to disable the script debugger when the system is in lock down mode. System lock down mode is checked each time the debugger state is changed, which occurs many times in a tight loop for variable processing, and the system check results in a significant slow down.

The fix is to cache the system lock down mode for each script debugger instance.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[daxian-dbw]

LGTM

[iSazonov]

LGTM with one minor comment.

For information (used artifact from the PR)

this extra file attribute check is addressed in #10244 but SaferIdentifyLevel still is on top.

[PaulHigin]

@TravisEz13 This is ready to merge.

[TravisEz13]

@PoshChan Please retry macos

[PoshChan]

@TravisEz13, successfully started retry of PowerShell-CI-macOS

[TravisEz13]

@PoshChan please rerun static

[PoshChan]

@TravisEz13, successfully started rebuild of PowerShell-CI-static-analysis

[TravisEz13]

@PoshChan Please remind me in 30 minutes

[PoshChan]

@TravisEz13, this is the reminder you requested 30 minutes ago

[iSazonov]

Is there a plan to investigate an influence of mentioned security update on Safer API?
In scenarios like Pester and Get-Module -Listavailable -All we call the API the every file that sometimes can slow down execution significantly.

[PaulHigin]

@iSazonov Is there a repro that demonstrates the perf regression?

[iSazonov]

@PaulHigin Yes, I created #10309 to show that the API is very slow.

[ghost]

🎉v7.0.0-preview.3 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes

[ghost]

🎉v6.2.3 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes

[mlee-bittitan]

Is there any plan/ETA for when this fix will be applied for Windows PowerShell 5.1?

[Hypernut]

Seriously, this needs to be fixed in 5.1.
In many corporate environments it would be huge deal and weeks of compatibility testing to upgrade to v7 because of this.

We have a huge repository of scripts running on thousands of machines.
I just ran one of our lager script in the debugger, it took 3 1/2 hours instead of 15 minutes to complete.
This means we can't use the debugger in test and pre-prod environments anymore.
This is a mayor problem!

[iSazonov]

@Hypernut Windows PowerShell is a frozen project and only security updates can be added.
Are your scripts compatible with the new version? Your team should plan to migrate to 7 version.

[Hypernut]

That is what I was talking about. We have hundreds of script in production. Migrating them takes weeks of testing in different environments. For each of them!
As far as I understood is, Windows Powershell does not get new features. This is not a feature, this would be a bug fix for a major bug.

[PaulHigin]

cc @SteveL-MSFT

[iSazonov]

Migrating them takes weeks of testing in different environments. For each of them!

@Hypernut I would expect 7 version to become dominant in the next two years. So you go in right direction.
If you have great experience in the area you would could more actively communicate with MSFT team in the repo to resolve compatibility issues if possible and in PSSA repo to add more rules to detect compatibility issues.

[Hypernut]

Two years is two years. The bug is there now. And of course I am happy to help.

[daxian-dbw]

@Hypernut Just an update on this. We opened a bug internally to the team that owns Windows PowerShell 3 days ago, and the owner dev agreed to work on porting the fix.

[Hypernut]

Sounds good, thanks!

[PaulHigin]

@Hypernut We have been speaking with the the internal Microsoft CSD team, and it turns out that this fix has been applied to Windows PowerShell in the latest release of Windows. So you will see the fix with Windows 20H1 release, which was released in May 2020. There doesn't seem to be any plans to back port it to the older 19H1 release.

[Hypernut]

This is even worse. Now the alternative is to make a full Windows upgrade instead of "just" a PowerShell upgrade, which is an even bigger deal.
Amazing.
I have customers all over the industry. No one uses 20H1 in production environments yet. The standard "delay" is at least 6 months, up to year.

Is there no way to install the 20H1 - Powershell 5.1 into 19H1?

[PaulHigin]

You can make a request to backport the fix via Microsoft UserVoice. The performance degradation only occurs when script breakpoints are set, which is unusual for production, and the workaround is to remove all breakpoints.

[Hypernut]

Of course there are no breakpoints in production, but in test- and pre-prod-environments, which -apart from the to be tested script- have to be exactly like prod. I have to be able to trace errors or unexpected behavior in those environments.

[aolszowka]

To resurrect this thread, similar to @Hypernut we are in the same boat; we've got plenty of 5.1 Scripts in Production environments and cannot lift to 7.

We're in the middle of trying to lift this process to Azure DevOps Pipelines Microsoft Hosted Agents and we're encountering the issues that have been well documented on at pester/Pester#1318.

Our unit testing utilizes Pester's Code Coverage, which in turn utilizes PowerShell's Breakpoints. It currently is covering over 2,100 lines and a process that should take 5-8 minutes is taking between 18-35 minutes which is not feasible for moving our builds to Microsoft Hosted Agents.

As per the above linked issue in Pester, they cannot do anything as they are dependent upstream on the performance of these breakpoints. Is there any path forward?

[iSazonov]

@aolszowka Please open new issue with your business scenario description.

[daxian-dbw]

@aolszowka Quoted form @PaulHigin's comment above:

So you will see the fix with Windows 20H1 release, which was released in May 2020. There doesn't seem to be any plans to back port it to the older 19H1 release.

Are you able to choose the image to use for the MS hosted ADO agent?

[aolszowka]

@daxian-dbw Unfortunately no; and based on that it looks like this is most likely the problem:

https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md

OS Version: 10.0.17763 Build 2237
Image Version: 20211018.0

I confirmed that myself with the following YAML:

---
pool:
  vmImage: "windows-2019"

stages:
  - stage:
    jobs:
      - job: "Build"
        displayName: "Build"
        condition: true
        steps:
          - task: PowerShell@2
            displayName: "Get Version"
            name: "getVersion"
            condition: always()
            inputs:
              targetType: inline
              script: |
                systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
              pwsh: false
            timeoutInMinutes: 5

Which outputs:

OS Name:                   Microsoft Windows Server 2019 Datacenter
OS Version:                10.0.17763 N/A Build 17763

I am going to go ahead and open an issue with that team; and link them back to this for reference.

@iSazonov I will hold off opening a PowerShell specific issue as based on the above it seems like PowerShell is thinking this should be resolved.

GitHub

virtual-environments/Windows2019-Readme.md at main · actions/virtual-environments

GitHub Actions virtual environments. Contribute to actions/virtual-environments development by creating an account on GitHub.

[daxian-dbw]

@PaulHigin Do you know if the 20H1 update was applied to Windows Server 2019?

[PaulHigin]

No, the fix was not backported.