You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In pwsh on linux, hold down a key, and observe the rate at which characters are added. Then run Read-Host and observe the rate at which characters are added - it is much slower. In both cases I'm just holding down the f key. This is even slower in Cloud Shell, but the issue is reproducible in a regular terminal on ubuntu. The characters are also buffered differently - if you hold down a key and then release it in the normal terminal, input stops quickly after you release it. In Read-Host, the characters are still being added to the input and displayed several seconds after you release the key.
Why does it matter? Several customers have complained. This also shows up when using Get-Credential.
Screen recording below
>$PSVersionTable
PSVersion 6.1.0
PSEdition Core
OS Linux 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018
This is affecting the customers' experience with the Cloud Shell on docs.microsoft.com, especially in cases where we work with them to provision Azure resources and they need to specify information such as VM names, passwords or resource group.
These interactive cmdlets including read-host, get-credential are handled by pwsh, yes?
I noticed that if you remove-module psreadline, regular stdout becomes lagging too. The behavior is much like read-host and get-cred. Does this mean the lagging could be caused by powershell engine? Of course pwsh depends PSReadline which should not be removed.
The issue here is that PowerShell Core ConsoleHost has a very simple synchronous readline implementation. When you use Read-Host, it calls back into the host's ReadLine() implementation which is not designed to be performant. PSReadLine on the other hand is what you use in the console when not using Read-Host. PSReadLine buffers the input asynchronously and renders them on a different thread.
In the efforts of a (hopefully) simple fix, is it possible for PSReadLine to override the Read-Host with a function/cmdlet/alias that works in a similar fashion to how it handles standard input?
I started some ConHost optimizations, but my PR for ConHost has been awaiting a review for several months. I could continue these optimizations, but reviews is required.
PSReadLine could be modified to support Read-Host, but it might be simpler and/or smarter to better understand why Console.ReadLine is so slow.
To modify PSReadLine to support Read-Host, you'd need to:
Not use the PowerShell syntax coloring
Not share history, possibly not use history at all
Add support for reading a secure string
Disable completion
I've briefly considered a readline implementation that implements parts of the LSP for reuse in other tools like csi and fsi, if that ever gets built, then I think Read-Host would be a great use case.
I don't think it's Console.ReadLine itself that is slow, but the ReadLine loop in ConsoleHost that is slow. It's single threaded and does a bunch of processing per key press.
It's been brought up that when pwsh prompts for mandatory parameters, the experience is not great and typically users ctrl+c and retype the command with the parameter to get tab completion. We should support using PSReadLine for prompting (which should also cover this read-host case) while still supporting tab completion for a parameter while also resolving the issues Jason Shirk (@lzybkr) brought up above for general ReadLine for strings.
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
Activity
dend commentedon Oct 8, 2018
This is affecting the customers' experience with the Cloud Shell on docs.microsoft.com, especially in cases where we work with them to provision Azure resources and they need to specify information such as VM names, passwords or resource group.
jianyunt commentedon Oct 8, 2018
I think I discussed it with Bruce Payette (@BrucePay) before. We also observed the issue.
These interactive cmdlets including read-host, get-credential are handled by pwsh, yes?
I noticed that if you remove-module psreadline, regular stdout becomes lagging too. The behavior is much like read-host and get-cred. Does this mean the lagging could be caused by powershell engine? Of course pwsh depends PSReadline which should not be removed.
SteveL-MSFT commentedon Oct 9, 2018
The issue here is that PowerShell Core ConsoleHost has a very simple synchronous readline implementation. When you use
Read-Host, it calls back into the host'sReadLine()implementation which is not designed to be performant. PSReadLine on the other hand is what you use in the console when not usingRead-Host. PSReadLine buffers the input asynchronously and renders them on a different thread.vexx32 commentedon Oct 9, 2018
In the efforts of a (hopefully) simple fix, is it possible for PSReadLine to override the Read-Host with a function/cmdlet/alias that works in a similar fashion to how it handles standard input?
iSazonov commentedon Oct 9, 2018
I started some ConHost optimizations, but my PR for ConHost has been awaiting a review for several months. I could continue these optimizations, but reviews is required.
lzybkr commentedon Oct 22, 2018
PSReadLinecould be modified to supportRead-Host, but it might be simpler and/or smarter to better understand whyConsole.ReadLineis so slow.To modify PSReadLine to support
Read-Host, you'd need to:I've briefly considered a readline implementation that implements parts of the LSP for reuse in other tools like
csiandfsi, if that ever gets built, then I thinkRead-Hostwould be a great use case.SteveL-MSFT commentedon Oct 24, 2018
I don't think it's Console.ReadLine itself that is slow, but the ReadLine loop in ConsoleHost that is slow. It's single threaded and does a bunch of processing per key press.
[-]Read-Host consumes input much more slowly than regular terminal[/-][+]Enable pwsh ReadLine to use PSReadLine[/+]SteveL-MSFT commentedon Jun 10, 2020
It's been brought up that when pwsh prompts for mandatory parameters, the experience is not great and typically users ctrl+c and retype the command with the parameter to get tab completion. We should support using PSReadLine for prompting (which should also cover this read-host case) while still supporting tab completion for a parameter while also resolving the issues Jason Shirk (@lzybkr) brought up above for general ReadLine for strings.
iSazonov commentedon Jun 11, 2020
A tracking issue in .Net Runtime repo dotnet/runtime#800
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.