Startup performance PowerShell 7.2.0-Preview.1

Here PerfView trace https://ru.files.fm/u/n2hqqsr7z

• ~GetFileAttributesExW() reported to .Net Runtime. I hope they can reduce these operations https://github.com/dotnet/runtime/issues/44545~ The referenced .NET issue was addressed.
• PR #14411 newtonsoft.json It read powershell.config.json Expected perf win 50-100 ms.
  • There is an idea to use defaults and exclude the file at all in release version. (We still need the file for preview versions for experimental features turn on/off.)
  • We should migrate to .Net System.Text.Json API. It is expected being faster.
• ~CreateManifestAndDescriptors() I don’t know if it’s possible to remove this delay. Tracking issue https://github.com/dotnet/runtime/issues/45466~ This only appears when collecting ETW traces. See https://github.com/PowerShell/PowerShell/issues/14268#issuecomment-739464805
• ~PR #14320. SemanticVersion.op_Implicit There is dead code that we need to remove because we haven’t received any feedback that it is needed. Expected perf win about 50 ms.~ PR closed because it’s not dead code.
• ~microsoft.applicationinsights Perhaps we could lazy the initialization. PR #14281 - perf win from 30 to 100 ms.~
• PR #14283. InitialSessionState…cctor() See GetAppLockerPolicy() method. Perf win ~10-30 ms
• ~Creation of explorer menu should be moved to right place (from line 184 to line 220) - it makes no sense to run the code in server mode - and be probably runned in background.~ Answered in https://github.com/PowerShell/PowerShell/issues/14268#issuecomment-740353164
• Use StringComparison.Ordinal insted of StringComparison.CurrentCulture in string.StartsWith() in ConsoleHost.Start(). It is slow ICU initialization. PR #14298 - perf win ~5 ms.
• We use string.ToLowerInvariant() in CommandLineParser.GetSwitchKey(). It is slow ICU initialization - 26 ms! Reported to https://github.com/dotnet/runtime/issues/40942#issuecomment-735383698
• PR #14298. Use StringComparison.Ordinal instead of StringComparison.CurrentCulture at startup time. It removes early Culture initialization.
• PR #14303. Use OrdinalIgnoreCase in CommandLineParser. It removes early Culture initialization.
• PR #14323. Exclude string.ToLowerInvariant() in GetEnvironmentVariableAsBool(). It is slow ICU initialization.
• Exclude loading System.Diagnostics.FileVersionInfo.dll on Windows in AmsiUtils.Init(). https://github.com/PowerShell/PowerShell/pull/14332#issuecomment-739549844
• ~Review how we use (1) Jit paramteters, (2) crossgen.exe for same assemblies (Build.psm1) - it seems no effect on startup scenario~ Use .NET crossgen properties in .csproj files. All shipped assemblies are R2R images now.
• Benefit from modern CrossGen2 and dotnet-pgo https://github.com/dotnet/runtime/tree/master/src/coreclr/tools/dotnet-pgo

Environment data

Name                           Value
----                           -----
PSVersion                      7.2.0-preview.1
PSEdition                      Core
GitCommitId                    7.2.0-preview.1-62-g15e4e8a6af2f120bbd1eef8607131d878677c0ad
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[sergeevabc]

Question from https://github.com/PowerShell/PowerShell/issues/6443:

Dear fellows, I am tired that PS 5.1 currently installed on my Windows 7 x64 (please, don’t even mention W10) is unable to properly execute BOM-less *.ps1 with UTF8 strings (e.g. $singer = "Björk"; echo $singer outputs as BjГ¶rk). That’s why I downloaded both (portable) PS 6.2.7 and 7.2.0p7 and run as follows pwsh.exe .\test.ps1. Indeed, they have no problem outputting UTF8, but the execution time is 2x slower: 320ms (5) vs 694ms (7) vs 760ms (6). Delay is noticeable and annoying. …There was a trick to make early PS run faster by ngen install. Is there something similar here, or we’re doomed?

Thank you in advance.

[bergmeister]

Regarding point 7: Feel free to move the code to a more appropriate place but just to let you know that inside it, it creates a non-blocking thread so it should incur hardly any cost, there is also low level code making the procedure a no-op in the case of non-interactive shell