Set-PSReadLineOption is slow when called from profile

[RoadToDream]

Prerequisites

• [X] Write a descriptive title.
• [X] Make sure you are able to repro it on the latest released version
• [X] Search the existing issues, especially the pinned issues.

Exception report

N/A

Screenshot

measure-command { Set-PSReadLineOption -HistoryNoDuplicates -EditMode Windows }

Environment data

PS Version: 7.4.2
PS HostName: ConsoleHost
PSReadLine Version: 2.3.5
PSReadLine EditMode: Windows
OS: 10.0.22621.1 (WinBuild.160101.0800)
BufferWidth: 181
BufferHeight: 23

Steps to reproduce

This has been reported in #476, but closed without much context been provided. Set-PSReadLineOption calling from profile will take much longer than calling from a running pwsh. Adding a single line of Set-PSReadLineOption in profile delays start up time over 100 ms. I wonder how is the 11 ms load time is achieved mentioned in that issue and what can I do to ease the issue.

Expected behavior

Same execution time when running from profile.

Actual behavior

Much longer execution time in profile.

[daxian-dbw]

Do you mean Set-PSReadlineOption is slow in general or only the Set-PSReadLineOption -HistoryNoDuplicates -EditMode Windows is slow for you?

Adding a single line of Set-PSReadLineOption in profile delays start up time over 100 ms.

I cannot reproduce the issue locally. I have 3 calls to Set-PSReadlineOption in my profile and cannot observe a delay as reported

[RoadToDream]

Hi, for me it's the general Set-PSReadlineOption. Even a single Set-PSReadlineOption will introduce over 100 ms delay. If it's not reproducible I assume there is something wrong from my end, may I ask if there is any log I may collect that can help diagnose this issue? Thanks

[daxian-dbw]

Even Set-PSReadlineOption -BellStyle None takes over 100ms for you in profile?

may I ask if there is any log I may collect that can help diagnose this issue?

If you really want to dig into it, I guess you will have to collect traces using prefview, which is not easy for a starter.

You will need to build PSReadLine locally with the Release configuration .\build.ps1 -Framework net462 -Configuration Release and use the produced module to collect the trace. After the build, you can find the produced PSReadLine module under .\bin\Release\PSReadLine, and the .pdb file for Microsoft.PowerShell.PSReadLine2.dll can be found under .\PSReadLine\bin\Release\net462.

[RoadToDream]

That's true.

Thanks for the instruction. I am indeed a starter for C# but will give it a try

[daxian-dbw]

There are other ways for profiling, maybe easier than using the perfview. See https://github.com/dotnet/performance/blob/main/docs/profiling-workflow-dotnet-runtime.md https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-trace

[gwojan]

Hi, for me it's the general Set-PSReadlineOption. Even a single Set-PSReadlineOption will introduce over 100 ms delay. If it's not reproducible I assume there is something wrong from my end, may I ask if there is any log I may collect that can help diagnose this issue? Thanks

Just out of curiosity do you have some other software running that might be causing issues, ie: Defender, FireEye, etc. My work laptop frequently has performance issues running my wacky PowerShell profile because of those two specific applications scanning all the things. 😭

My latest issue was I have a function Get-Fortune which calls into WSL using fortune, cowsay, and lolcat to display my fortune in each new PowerShell session. About two weeks ago my profile load times went from maybe one second to 35 seconds! It turns out I have a really old script that maps a persistent drive to a now non-existent resource. Waiting for WSL was causing my extreme slowdowns so once I removed the mapped drive performance was back to normal.

[RoadToDream]

Thanks for the suggestion. I can take a look, but honestly, I don't think that's the reason. I have disabled Defender.

[RoadToDream]

Let me put some profiling result here. I am using prefview to profile, each configuration is executed 10 times for averaging.

Fig. 1 With PSReadLine option: Set-PSReadLineOption -EditMode Emacs

Fig. 2 Without PSReadLine option

[RoadToDream]

Flame graphs Fig. 1 With PSReadLine option: Set-PSReadLineOption -EditMode Emacs Fig. 2 Without PSReadLine option

[RoadToDream]

PerfViewDataNoOptionLoop.View1.perfView.xml.zip PerfViewDataWithOptionLoop.View1.perfView.xml.zip

[RoadToDream]

I am not sure if this information is sufficient to help diagnose the issue, but if not, please let me know and I can provide more details. I am much more familiar with VTune, so if that would help, I can provide information from that as well.

Based on my findings so far, the issue seems more likely to be related to PowerShell rather than PSReadLine.

[StevenBucher98]

Just out of curiosity does the startup time only increase with that particular command or does it increase with anything in your profile?

[RoadToDream]

Hi @StevenBucher98, it increases with any line with Set-PSReadlineOption. However, adding one config line of Set-PSReadlineOption takes about same time as adding four or five.

[konosubakonoakua]

Same here.

[Mattwmaster58]

re-importing the profile . $PROFILE is very quick, for me 5 options takes 5ms But on startup, it's very slow:

PS ~\Documents> pwsh
PowerShell 7.5.2
psreadline in 210ms
Loading personal and system profiles took 656ms.

PS ~\Documents> . $PROFILE
psreadline in 4ms

My guess is maybe windows defender related stuff. You can see psreadline is not the only thing that's making the profile at startup slow, it only accounts for 1/3rd of it in my case. Perhaps a broader powershell issue.

edit: I checked with procmon, the majority of the time was waiting for other executables (git and fzf) which were expected in my case. So if you're having this issue maybe check with procmon to see what it's running and for how long?