-
Notifications
You must be signed in to change notification settings - Fork 234
Add Thread.Sleep(100)
to throttle REPL when it's non-interactive
#1694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Thread.Sleep(100)
to throttle REPL when it's non-interactive
#1694
Conversation
My guess is that you're seeeing this issue because PowerShellEditorServices/src/PowerShellEditorServices/Services/PowerShell/Host/PsesInternalHost.cs Lines 599 to 604 in b433b0f
Instead of a sleep, I'll see if we can use something from System.Threading.Channels. In our use case it's only non-interactive during testing, as the extension provides an interactive console REPL and so |
Ah gotcha! The code makes more sense with that in mind. Right, |
@andschwa @colinblaise What if in the short term we move the Thread.Sleep onto line 603 so this only affects our oddball scenario where ConsoleReplEnabled is false Ideally we'd get this done pretty quick as we're trying to launch Intellisense in our product next week and I don't want to use a custom PSES build. |
@dkattan I'd be fine with that! With a comment to the effect of "Throttle the REPL loop with a sleep because we're not interactively reading input from the user." |
…eading input from the user
Done. Only sleeps now when |
@andschwa LGTM! |
Thread.Sleep(100)
to throttle REPL when it's non-interactive
We integrated PSES into our project and noticed a considerable increase in CPU usage while PSES is running.
I downloaded the PSES project and was able to step through the code and see it is executing a
while
loop with zero throttling.Adding a
Thread.Sleep(100)
brought down the CPU of my application considerably when PSES was running. I did not notice any increase in latency when using PSES itself either.Here are the parameters we are using:
Using
Thread.Sleep(100)
is heavy handed, so the solution can likely be expanded to either take in a variable that specifies the sleep amount, or better yet, remove thewhile
loop entirely and refactor it into an even-driven approach and execute only when we have data in_taskQueue
.This solution works for us, but I am not at all familiar with the rest of this project. So please let me know if there are any obvious disadvantages with making this change. Thanks!